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(DIAL) . The design permitted systematic language implementation and 
easy language modifica\ion and used a translator writing system (TWS) 
to generate compilers- Authoring by teachers required simplicity of 
the language and its operational environment. A measared high level 
of user acceptance proved the design to be sound, and a significant 
reduction in authoring time was achieved. DIAL was observed to be a 
superior language, for machine intrusion was low and other syntactic 
improvements were possible. An answer-evaluating technique, called 
the sieve, was devised and a syntactically improved DIAL/2 language 
derived. The TWS helped to implement DIAL and to remediate language 
weaknesses. Although the TWS was not available for the command 
language of the operational environment, the human-factors debugging 
period revealed the desirability of such, (Author/PB) 
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JONATHON CRAIG MUDGE . Human Factors in the Design 
of a Computer-Assisted Instruction System (Under 
the direction of DR. FREDERICK P. BROOKS , JR.) 

This research is an exploratory case study of ease- 
of~use factors in man-computer interfaces. 

The approach has been to build and evaluate a real 
man-machine system, giving special attention to the form 
of all man-machine and machine-man communications. Author- 
controlled computer-assisted instruction was selected. 
Such a system has three principal interfaces: student- 
system, author-system, and computer programmer-system. 

The method was to design, build a large subset of the 
design, r e systematic observations of the three inter- 
faces in use , and then iterate on the design and on the 
observations. The system has been in regular class use 
for a year. 

Interactive development of course material by authors 
execution of instructional programs by students, and the 
requisite administrative tasks are integrated into a 
single production-oriented system. The nucleus, of the 
system is a new display-based interactive author language, 
DIAL. The design demands a language implementation which 
is systematic and which permits easy language modification 
A translator writing system, based extensively on McKeeman 
ass is ts computer programmers in generating compilers for 
new versions of the language. 



Two of the design assumptions (that the course author 
is always an experienced teacher and that he does his own 
programming in DIAL, without an intermediary CAI language 
programmer) are major departures from most CAI authoring 
systems. Professorial-level authoring imposes stringent 
requirements on the ease-of-use and simplicity of the 
language and the operational environment in which it is 
embedded , 

A measured high level of user acceptance proved the 
soundness of the design and illuminated the relatively few 
mistakes made. A factor-of-f ive improvement in authoring 
time over data published for other systems was observed. 
Several improvements in DIAL over existing CAI languages 
were observed. The underlying machine intrudes much less 
than in existing languages, and there are other syntactic 
improvements . The provision in DIAL of a pattern matching 
function allowed a very general answer-evaluating techni- 
que, called the sieve , to be devised. Analysis of author 
use of DIAL has derived DIAL/2, which is radically differ- 
ent syntactically but only slightly enriched functionally. 

The translator writing system proved very useful in 
progressive implementation^of DIAL and. in the remediation 
of language weaknesses as they were discovered. Although 
a translator writing system was not available for the 
command language of the operational environment, the human- 
factors debugging period (necessary for all user-oriented 
systems) revealed the desirability of such. 
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CHAPTER 1 
INTRODUCTION 



1-1 User-orientation in system des ign 

1.1.1 Users, by and large, do not feel that computer 
systems are yet accommodatingly matched to their human 
users. People are flexible and can make remarkable 
adaptations to machine inflexibilities. Machine designers 
have always exploited th&t flexibility, sometimes 
ruthlessly. However, the more a user is forced ;o adapt, 
the less productive he will be. Thus, just as aircraft- 
cockpit designers have done, computer system designers 
are turning to the study of ease-of~use factors in the 
man-machine interface . 

1.1.2 The approach in this thesis research has been to 
design and evaluate a real man-machine system. Author- 
controlled computer-assisted instruction was selected for 
three reasons. 

(1) The man-machine system required was small enough 
for one person to design a total, production- 
oriented , hence real , sys tern . 



(2) The resulting syst n was potentially useful for 
instruction at the University. 

(3) The closest possible user feedback obtains ; 
the tool builders and users are one. 

The method of investigation was to design, build a 
large subs et of the des ign , make systematic observat ions 
of users , and then iterate on the des ign and on the ob- 
servations . 

The nucleus of the design is a display-based inter- 
active author language, DIAL. Interactive development of 
course material by authors, execution of instructional 
programs by students , and the requisite administrative 
tasks are integrated into a single system. The aesign 
demands a language implementation which is systematic 
and which permits easy language modification. A translator 
writing system, based extensively on McKeeman's, assists 
computer programmers in generating compilers for new 
versions of the language. 

The evaluation of the design focuases on the three 
principal interfaces: student-system, author-system, and 
computer programmer-system . 

Two of the design assumptions (that the course author 
is always an experienced teacher and that he does his own 
programming in DIAL, without an intermediary CAI language 



programmer) are major departures from most CA'l author in) 1 , 
systems • Prof ess or ial- level authoring impose? stringent 
requirements on the ease-of-use and simplicity o f the 
language and the operational environment in which it is 
embedded. Because it has been forced to adapt more to the 
user* than most CAI systems, this system is probably a better 
tool for studying human factors than most . 

1.1.3 The scope of the research is the syntactic as 
opposed to the semantic elements of a man-machine system. 
That is, I am concerned with the form of communication 
between a system and its user ? as contrasted with its 
meaning. The more obvious syntactic elements include 
programming language syntax and command-language syntax . 

I also view the following as essentially syntactic in the 
sense of pertaining to form of communication : the phys ical 
work-station design and its operating procedures; the 
removal of redundant operations in order to minimize 
user action; and the invention of general purpose 
primitives to subsume s everal special operations . 

1.1.4 The following is a selection of the results of this 
research. 

A measured high level of user acceptance proved the 
soundness of the design and illuminated the relatively few 



mistakes made. A f actor-of-f ive improvement in authoring 
time over data published for other systems was observed. 

Several improvements in DIAL over existing CAI 
languages were observed: there is much less intrusion of 
the underlying machine; some general 5 powerful, and easily 
used mechanisms have been borrowed from general program- 
ming languages; and a consistent syntax embodies its func- 
tional facilities . 

Analysis of author use of DIAL has derived DIAL/2, 
which is radically different syntactically but only 
slightly enriched functionally. This contrasts with my 
early prediction that DIAL would be deficient semant ically s 
not syntactically . 

The translator writing system proved very useful in 
progressive implementation of DIAL and in the remediation 
of language weaknesses as they were discovered. It is 
expected to be very useful in implementing DIAL/ 2. 

Although a translator writing system was not avail- 
able for the command language of the operational environ- 
ment, the human-factors debugging period (inherent in user- 
oriented systems) revealed the desirability of such. 

The provision in DIAL of a pattern matching func- 
tion allowed a very general answer evaluating technique, 
called the sieve, to be devised. 



1. 2 An ap proa ch to resea rch in c omp u Lor-iisr*.! :> Uvl 
instruction ( CAI ) 

The last decade has seen computer-assisted instruc- 
tion go through two stages , an experience not uncommon 
in several computer application areas . In the first 
stage, potential users were led to expect great benefits 
from the use of computers in the instructional process. 
The rapid increase in the availability of time-sharing 
systems added support to the arguments of the CAI pro- 
ponents. The second stage has been the realization that 
the success of CAI has fallen far short of the claims 
made for it 5 and that a reassessment of approaches should 
be made . 

The approach taken in this thesis postulates that 
real measurable progress can be made by restricting the 
instructional subject matter to subjects which are highly 
structured. Elementary computer programming has been 
chosen from the class of structured subjects for two 
reasons: (1) researchers will be professionally familiar 
with the subject matter and its pedagogy, and (2) the 
research results can be directly applied and measured 
in an existing course at the University. 

It must be emphasized that this project is con- 
cerned with computer science aspects of CAI rather than 



purely educational aspects- Examples of effort;*, in th:is 
latter category are those by Stolurow [ 1968 J, who is con- 
cerned with the psychological foundations of tedti.l:.; 
learning, and by Bunderson [1970] , whose major research 
effort is on the design of instructional programs. More- 
over 3 thera are computer science areas which have been ex- 
cluded from the scope of this project, e.g., CAI hardware 
research (being attacked on a large scale by the PLATO 
project [Bitzer and Skaperdas, 1970]), and 'natural' 
language question-answering research. This latter area i- 
typical of many research areas which have long-term appli- 
cations in CAI, and relate to the system designed in this 
project insofar as its flexibility allows new developments 
to be incorporated as they become available. 

Two papers which do well in capturing the current 
status of CAI are '[Bundy, 1968] and [Alpert and Bitzer, 
1970]. 

To be a valid tool, both for the University and for a 
study of human factors, the system designed has to be 
total and production-oriented. To be total, it has to 
serve all classes of users associated with the CAI environ 
ment: students, authors, proctors, and instructors in 
charge of CAI classes. 1 The implications of a production, 

^In this thesis, this operational environment is 
collectively referred to as the CAI System , or, for short, 
the Sys tern . 



rather than an experimental, system permeate both design 
and implementation . The production implications inc ludo : 

(1) concurrent multiple-author and multiple-student 
use ; 

(2) complete treatment of abnormal termination 
(ABEND) situations ; 

(3) comprehensive supporting programs for 
administrative j obs ; 

(4) procedures for recovery after system failure; 

( 5 ) efficient programming of the implementation ; 

(6) operational procedures for the CAI Center. 

1.3 The UNC CAI Project 

The current computer-assisted instruction work at 
the University falls into several project areas, which 
may roughly be classified into student-controlled CAI, 
teacher-controlled CAI, and author-controlled CAI. This 
thfisis results from work done in Phase II of the author- 
controlled project. Phase I was the development of a 
conventional Computer Administered Programmed Instruction 
(CAPI) System [Brooks, 1970] using an IBM 1050 audio- 
visual terminal (typewriter-based), for teaching a 
beginning course in the programming language PL/I. 

The Phase I system was converted, with as few changes 
as possible, to operate on a Computer Communications Inc. 
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CC-30 terminal (CRT-based)- As a result, feasibility 
of this terminal for the envisaged CAI work was 
established and the Phase II objectives laid down. 
This second phase called for the following. 

(1) the installation of new communications equipment: 

a medium-speed leased line to the Triangle Univer- 
sities Computation Center (TUCC) , a general purpose 
campus computing facility, to give character 
speeds beyond the 15 character/second possible 
via dial-up facilities . 

(2) six CC-3Q terminals, each consisting of a CRT, 
keyboard, light pen, and random-access slide 
projector. 

(3) the building of a monitor program for the CAI 
region of Large Capacity Storage at TUCC to con- 
trol the programs In the region and to provide 
communications device programming support , 

(4) the design and building of student/author work 
stations based on the CC-30 terminals . 

( 5 ) the development of a CAI control program which 
simultaneously presents course material from 
several different courses to several student 
work stations . 



(6) the design of an author language and building ol an 
incremental compiler which generates code for pre- 
sentation as course material by the CAI control 
program. 

(7) the preparation of course material for an elementary 
programming course in PL/I . 

(8) evaluation of the system by class trial. 

Mr. Gary D. Schultz [19733 reports items (1), (2), 
and (3), which form his Chapel Hill Alphanumeric 
Terminal (CHAT) System. 

This thesis reports items (4) through ( 8 ) . The 
course material, item (7), was programmed by Professor 
F. P. Brooks, Jr. The off-line supporting programs, 
e.g., the student file maintenance program, were written 
by other CAI Project workers (Section 5.7) to my external 
specifications . My contributions are the design of ( 4 ) , 
(5), (6), and (8), and the implementation of (5), (6), 
and (8) . 

1 . 4 Language design in compute;? science 

Language design is an art. Given a particular ob- 
jective, there is no algorithm for designing a program- 
ming language to meet that objective; there is not even 
any clear delineation of various tradeoffs involved , let 
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alone any quantitative measures of them [Sammet, 1969]. 
In the remainder of the thesis, I therefore: 

attempt to define the objectives which have been 
set ; 

discuss the design decisions made (pointing out what 

are thought to be tradeoffs involved); 
attempt to see if the objectives have been met. 



CHAPTER 2 
EX TING CAI t'YGTEMS AND LANGUAGES 



2 . 1 The scope of the chapter 

A wide variety of languages and systems is being used 
for programming interactive use of convpnters for instruc- 
tional purposes . 

Before turning to describe that subset which is 
appropriate for this chapter, we must define the area of 
instructional use of computers at which DIAL is directed. 

This area is based on presentation of successive 
11 f rames" or units of course material , to a student . In 
each frame the student is expected to respond in an 
anticipated manner to the material presented to him in 
that frame. The order of presentation of frames is 
under the control of an author by means of the instruc- 
tional strategy he has programmed into his course material. 
Since an author is the agent controlling the interaction 
between student and computer system, this area is usually 
called author - controlled CAI . Two other modes can be 
distinguished. Consider a computer graphics system 
programmed to display step-by-step graphic solutions to 
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numerical analysis problems [Oliver and Brooks ; 1969], 
Hands-on laboratory use of this system by individual 
students is an example of student-controlled C/.I. Teacher- 
controlled CAI is exemplified by the use of this same 
system by a teacher in front of a class of students . 

In this chapter 3 then , I discuss specially devised 
author languages for author-controlled CAI ; IBM 1 s Course- 
writer typifies this class of languages* 

The chapter specifically excludes the following . 

1. Discovery -mode systems 

Here the student presents questions, usually phrased 
in natural language, to a system which interrogates a 
highly-structured data base specially prepared to cover 
the subject matter being taught . Examples of such systems 
are Thompson's REL System [1969], Simmons f s PROTOSYNTHEX 
III [1970] and Carbonell's SCHOLAR [1970]. Incidentally, 
experience with these experimental systems is aiding 
research being done on the linguistic and semantic analys is 
of constructed responses in author- control led CAI . 

2 . Conversation machines 

ELIZA [Weizenbaum, 1966] is the best known of those 
systems which, in providing conversation within a limited 
context, have been used for CAI. 
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3. Interactive programming languages 

Some writers include in CAI the' use of interactive 
programming languages by students for working exercises, 
programming simulations, etc. This aspect of CAI is' 
clearly excluded from this chapter; however, such 
languages have been adapted as author languages, and 
these are discussed in Chapter 3. 

4. Highly tair ired systems 

An interesting example of this type of system is 
the TEACH System [Fenichel, et al. , 1970] developed at 
the Massachusetts Institute of Technology to ease the cost 
and improve the results of elementary instruction in 
computer programming. The system was designed for this 
subject matter only, and includes a specially designed 
programming language, UNCL, in which a student writes 
specific programs requested of him by TEACH. The system, 
by monitoring the execution of such a program, attempts to 
present meaningful feedback to the student. 

5 . Course generators 

An author enters course material as a structured file; 
standard procedures draw exercises from the file and present 
them to a student. Such systems are particularly useful for 
drill-and-practice and have so been used for arithmetic and 
spelling drill. Examples of such systems are TSA (Teacher 
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Student Algol) at Stanford University [Suppes, et al. , 
1968] and CG-l (Course Generator) [Meadow, et al., 1968]. 

Author languages for such systems are characterized 
by having 

( 1 ) data structures - usually vectors ~ for storing 

questions , answers and scores , 
and (2) a greater naming freedom than the languages 

des cribed in later sections of this chapter . 
A recent system developed by Wexler at the University 
of Wisconsin [Wexler, 1970a and b 1 should generate course 
material and interactions which appear quite intelligent 
to the student. His system, which has a structured 
information net of factual material, has made use of 
results from artificial intelligence and natural language 
processing which are common to the discovery-mode systems 
mentioned above. 

2 . 2 Coursewriter systems 

2.2.1 The IBM Corporation is responsible for the most 
widely used author languages and CAI systems , all based on 
the original Coursewrit er I for the IB A 14-00 series of 
computers. Coursewriter II and Coursewriter III are 
available as program products from IBM and are functionally 
complete , serving students , authors , and administrative 
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personnel in the CAI environment. Since CWIII is typewrite 
terminal based and CWII is CRT terminal based, they are not 
in a successor relationship nor are they strictly compati- 
ble, and features of both will be described. 

2.2.2 Coursewriter III [IBM 1969a, b, and c; 1970a] 

2.2.2.1 Hardware 

The stucent/author station is an IBM ±050 typewriter 
terminal with slide projector. It uses a host computer 
system, the IBM System/36 0, via a low-speed communications 
line. A random-access audio tape can be attached to the 
station as a special option . 

2.2.2.2 The CWIII Language 

Variables operated on by a CW program are of six 
types and are described in the following table. They 
are called storage areas, and one copy is kept for each 
student . 
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Name for 



Storage area 


addressing 

in CW language 


Attributes 
of contents 




counters 


C U 


— CoLl 


s igned integer 


dux ierb 


bO 


- b6 


character 


bO is 








strings up 


the stu- 








to 100 


dent 








characters 


input 








in length 


buffer 


return registers 


rl 


- r6 


label 




swit ches 


sO 


- s31 


binary digit 




course parameters 


pO 


- p31 


binary digit 




auxiliary storage 


a 




byte string 





Other data types are character string constants and 
integer constants . 

Operations (statements) have the syntactic form 

operation code optional argument ( s ) 

modifier 

Text and questions are presented by the qu ^ rd, and 
operation codes which take as arguments a character string 
constant or a buffer. Arithmetic is specified by the 

ad , sjb, .Tip, and dv 

operation codes which take two integer arguments each. 
Assignment is specified by the Id operation code which 
takes two arguments (of the same type). Conditional and 
unconditional branching is effected by the 



17 



br operation code . 

The following example [IBM, 1969a: 20] illustrates 
each of these. 



Author Mode 

q5 

pr 

au{p) 146 (voice asks "spell capital. Albany is the copital of New York State,") 
ad l/c2 
sb c3/c3 
ep 

ad l/c3 
co capital 

ou(p) 147 (voice soys "Good. Next we will consider a homonym") 
od l/c4 
wo copital 

ou(p) 148 (voice soys "No. That is o homonym of the word J osked for. Try again. ") 
un No . 

br q5A//c3/ge/3 
ty Try again. 



Explonotion 

Example q5 uses counters and a conditional branch. The student is asked a question by the audio device. Al the 
end of the audio message one is added to counter two, which records the number of questions osked. Counter 3 is 
set to zero by subtracting if from itself. The system then pauses at ep and waits for the student to respond. After 
the response, one is odded to counter three, which counts the number of responses to the question. If the response 
matches the ca statement, the au statement immediately following is transmitted, one is added to counter 4, and 
the system moves on to the next pr, qu, or rd. Counter 4 notes the number of questions onswered correctly. 

The conditional branch takes the student ta label q5A if he hos mode three attempts to answer the question and 
has not yet onswered It correctly. 



Answer matching is specified by the operation code< 

ca , cb 3 wa , wb , aa , and ab » 

and certain misspellings can be ignored by a selective 
character string match specification. 
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One level of indirect addressing of a storage area 
can be specified with some operation codes- For certain 
statements , modifiers can be placed in parenthesis after 
the operation code to specify a modified operation- For 
example 

ca(l) re*d 

uses the 1 (line processing) modifier to eliminate the 
third character from response comparison. 

Two powerful features of CW are provided by the fn 
operation code and the macro facility. The argument field 
of a fn statement names a machine language subroutine and 
the arguments to be passed to it. The macro facility 
permits authors to write frequently-used course statement 
sequences in a skeleton form. Macro definition and 
invocation facilities are similar to those found in the 
macro facilities of assembler languages. 

In summary, the language can be characterized as an 
assembler-level language. Naming of data and the amount 
available seem to be the major restrictions. Auxiliary 
storage is used to increase the amount of space available, 
but its addressing is not by name but by absolute 
location , e.g., 

Id a, 738, 46/b3 
means that an area whose leftmost byte position is byte 
738 and whose rightmost is 783 is loaded into buffer 3. 
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With such restricted format, low-level commands, explicit 
addressing and restrictions on sizes of data areas . the 
sof tware implementation can be both fast and frugal in 
memory usage. Such implementation benefits are obtained 
at the cost of author convenience. 

2.2.2.3' Student use of the system 

The student signs on by typing the command s ign on, 
his student number preceded by the designation s^ and the 
name of the course for which he is registered. Once he 
has gained access to the system he has three commands 
available 

help 

££ tQ 
sign off 

The go to command allows him to invoke a particular 
section from a list of course sections provided by the 
author. 

2.2.2.4 Author use of the system 

An author signs on in the same manner as a student, 
but precedes his number by the letter a. 

CW statements are entered in fixed format using the 
1052 Print er-Keyboard . An author can view the execution 
of his course by signing on in student mode by prefixing s 
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to his number. Labelled segments of the course can be 
executed while he is in author mode by using the go to 
command. He returns from such an execution by entering 
"author :! . 

Other author commands are concerned with editing 
his program: 

insert after 
delete 
replace 
move 

A listing can be obtained by the command type . 

2.2. 2,5 Supervision and mo nitor commands 

The production orientation of CWIII systems is 
reflected in the comprehensiveness of the set of commands 
available to the system supervisors and monitors. The 
commands are for administrative tasks associated with 
student registration on the system and for changing 
system parameters [IBM, 1969c and 1970a]. 

2,2.3 Coursewriter II 

2.2.3.1 Hardware 

An IBM 1500 Instructional System consists of a number 
of student /author stations connected locally to a dedicated 
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computer, either the IBM 1800 or 1130. Kach station con- 
sists of a CRT display with light pen, keyboard and slide 
pro j ector . Random-access audio tape is opt ional . 

2.2.3.2 The CWII Language 

The language is essentially the same as CWIII, with 
the differences arising from the properties of the 
terminal. 

Explicit screen-formatting information is required. 
Light pen commands are included. In the following example 
[IBM, 1968: Part II, 77], the second and seventh statements 
show these two aspects. The former, the dt statement, 
displays ,! that barks' 1 beginning at coordinates (8,3) on the 
CRT. The latter, the c_a statement, specifies that a match 
occurs if the light pen touches the response area defined 
by a rectangle with its top left hand corner at coordinates 
(13,9) and depth 4 and width 3. 
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A feature of CVJII is the facility for special 
graphics display. 

Indirect address in g as in CWIII is not provided . 

2.2.3.3 Author use of the syste m 

The author can operate in one of two modes: assembly 
or checkout mode. In assembly mode the editing and list- 
ing commands are as for CWIII. In checkout mode, he can 
view the execution of a course' by entering the command 
EXECUTE. Provision is made for assembly from card input. 

2 . 3 Other languages 

2.3.1 WRITEACOURSE 

This language was developed at the University of 
Washington by a project aimed at producing a language 
which is natural for the teacher, highly readable, and 
suitable for machine-independent implementation [Hunt and 
Zosel, 1968]. 

2.3.1.1 The language 

The language, which is typewriter-terminal based, is 
very simple , having ten operations . The following example 
[Hunt and Zosel, 1968:926] illustrates display of text, 
use of counters (a number preceded by the symbol @), answer 



classification and branching, and its limited arithmetic 
capability. 

(1) SET @54,@41 TO 0 PRINT "WHAT DISCOVERY 

(2) LEAD TO LASERS?" [ 

(3) 3 ACCEPT CHECK "MASER" "QUASER" 

(4) "CANDLES" IF 1 CHECKS THEN GO TO 6 j 

(5) ADD 1 TO @41 IF 0 CHECKS THEN GO TO 40 j 

(6) IF 2 CHECKS THEN PRINT "THAT IS IN ASTRONOMY." 

(7) GO TO 40| 

(8) IF 3 CHECKS THEN PRINT "DO NOT BE SILLY." I 

(9) 40 IF @ 41 < 3 THEN PRINT "TRY AGAIN" GO TO 3 1 

(10) ADD 1 TO @5 4 PRINT "THE ANSWER IS MASER. "| 

(11) 6 PRINT "HERE IS THE NEXT QUESTION"] 

In the example, the first statement initializes 
counters 54 and 41 and prints a question, The statements 
in lines (3) and (4) specify three anticipated responses. 
If the first response matches the student's answer ("IF 1 
CHECKS") then the program branches to statement 6 on line 
(11). Unrecognized ("IF 0 CHECKS") and wrong answers 
cause incrementation of counter 41 and a branch to line 
(9). There a test on counter 41 determines whether the 
answer should be printed. 

Statements are grouped into lessons , and lessons are 
grouped into courses. Since it is possible to activate 
one lesson from another in the same course, a subroutine 
facility exists. It appears that parameterization would 
have to be done via counters known to both the invoking 
and invoked lessons . 
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2*3*1*2 The operational environmen t 

After a student has gained access to the system he 
types XEQ and then supplies the lesson name and course 
name when requested. 

The system is placed in author mode by the command 
///COMPILE. A new lesson is begun by ///PROGRAM NEW 
lesson-name /course-name . Each statement is checked for 
syntax errors as it is entered . The edit ing commands 
are ///ADD, ///DELATE and ///LIST. 

The WRITEACOURSE language translator, written in 
PL/I 5 is an incremental compiler producing an internal 
form which is interpreted at run time . This internal 
form is the only representation of the source code kept 
and is decompiled when a source listing is requested. 

2.3.2 FOIL 

This language was developed at the University of 
Michigan by a project aimed at producing a language which 
is easy to use, has good computational capability and whorjc 
implementation is sufficiently flexible to allow language 
modification [Hesselbart, et al. , 1969]. 

2.3.2.1 The language 

The language is for a student/author station con- 
sisting of a teletypewriter with optional slide projector. 
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It is a high-level language , as the following example 
[Hesselbart, 1968:94] illustrates 

TY WOULD YOU LIKE TO CONTINUE THE EXERCISE 
ACCEPT 

IF 'NO, ? GO TO FINISH 
IF 'YES 5 OK ? 

NUM = NUM + 1 
GO TO NEXT 
GO BACK PLEASE ANSWER YES OR NO 

Specification of an answer set is done as follows. 
A set of keywords to be treated as equivalent is written, 
separated by commas, between single quotes (as YES and OK 
in the above example). Exact matching is indicated by 
enclosing the anticipated responses in quotation marks. 
A digit following a list of keywords specifies the number 
of keywords which must match if other than one; a percent- 
age match can also be specified. 

The language is computationally powerful, allowing 
arithmetic expressions and vector data. 

There is no subroutine facility in FOIL*, however, 
FORTRAN subroutines can be invoked. 

The syntax of the language, although restrictive, 
is clean; moreover, source listings of programs reveal a 
clear logical flow. A good deal of the computational and 
logical power of the underlying machine is available to 
the author in a natural way. 
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2.3.2.2 The operational environment 

A student, once having signed on to the FOIL system, 

enters $S0URCE NAME to commence the course NAME. 

An author begins the creation of a course by entering 

$$RUN FOIL 6=*MS0URCE* 7=*MSINK* 8=coursename 

9=qualif ier 

$$S0URCE *MS0URCE* 
Card input facilities are also available. 

The implementation of FOIL is by an interpreter 
written in FORTRAN. The stated rationale for this is to 
enable an implementation (1) having few constraints on the 
syntax of the language, (2) permitting easy transfer to 
other time-sharing systems, and (3) allowing easy modi- 
fication of the language. 

To view the execution of a course, the author signs 
on as a student. Limited editing can be done while he is 
signed on as a student. Substantial revision is done by 
using a text editor unrelated to the FOIL system. 

2.3.3 PLANIT 

The language was developed at System Development 
Corporation and is claimed to be a multipurpose language 
for computer-human interaction , and s imple enough to 
allow non-programmers to use it easily [Feingold, 19^7 1. 
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The student/author station is a teletypewriter con- 
nected to a time-sharing system, The PLANIT system 
operates in four modes: lesson-building, editing, 
execution, and calculation. The student has access to the 
last two modes 5 an author to all four. 

A lesson is composed of a set of frames , of which 
there are five types: Problem, Question, Multiple Choice, 
Decision, and Copy. 

Lesson-building is done interactively with the author 
entering data (questions and answers) into the fixed format 
of the frames. The following example [Feingold, 1967:549] 
illustrates this. Note that data entered by the author 
follow an asterisk typed out by the system. 



Sys tem prompt and author respons e: 



FRAME 2.cj)(j)LABEL=*MATH 

2. SQ. 

-LETS SEE WHAT YOU REMEMBER ABOUT 
TEMPERATURE. USING F FOR DEGREES 

"FAHRENHEIT AND C FOR DEGREES CEN- 
TIGRADE, WRITE THE FORMULA FOR 

-CONVERTING FROM DEGREES FAHREN- 
HEIT TO DEGREES CENTIGRADE. 

-HINT: F=9*C/5+32 CONVERTS FROM 
CENTIGRADE TO FAHRENHEIT. 

3. SA. 

*4> FORMULAS ON 

*A+C=(5/9)*(F-32) 

*B F=9*C/5+32 
*C C=(5/9)*F-32 



Comments ' 

the question frame 
labelled MATH 
specify question 
question (one line at 
a time) 



end of question 
specify answer 
turn on algebraic 

matching 
+ signifies correct 

answer, answer A 
answer B 
answer C 
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4. SAT. 
• { A F: B:7 

*B R:YOUR ANSWER IS THE SAME AS 

THE ONE I GAVE YOU, TRY 

AGAIN . . . 
*A F: NOW YOU'VE GOT IT. B:15 
*B R:YOU ! RE STILL CONVERTING FROM 

CENTIGRADE TO FAHRENHEIT, TRY 

AGAIN . . . 
*BC F:NOTE THE DI FFERENCE . C : B : OUT 
*-R 
*-C: 



specify action to be taken 
A first time : Feedback 8 
branch to frame 
B first time 



A second time 
B second time 



The decision frame contains branching specifications. 

The aids to answer processing are phonetic comparison, 
keyword match and formula equivalence (by algebraic 
matching) . 

The calculation mode includes functions, matrices 
and statistical tables. 

2.3.4 TUTOR 

TUTOR [Avner and Venczar, 1969] is the principal 
author language for the PLATO system developed at the 
Computer-based Education Research Laboratory of the 
University of Illinois [Bitzer and Skaperdas , 1970]. 
The central computer is a Control Data 6400; the system 
is intended to serve 4000 student terminals on-line at once. 
The student/author work station is based on a plasma- 
display panel developed by the PLATO project. Slide 
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images can be superimposed on the text and graphic symbol: 
displayed on the plasma panel. Several spccxal keys, e.g. 
NEXT, BACK, HELP, and TERM, for lesson control, have been 
added to a typewriter keyboard. 

2.3.4.1 The language 

The author language was designed "... specifically 
for use by lesson authors lacking prior experience with 
computers" [Avner and Tenczar, 1969:1]. The following 
example illustrates display of text, slides, simple 
answer analysis, and branching [Avner and Tenczar, 1969:2! 



UNIT DAVINCI 

NEXT RUBENS 

PACK INTRO 

HELP DHELP1 

WRITE NAME THE ARTIST WHO 



WHERE 1301 

WRITE THE COMPLETE NAME IS LEONARDO DA VINCI- 
SPELL 



WHERE 1301 

WRITE YOUR ANSWER TELLS ME THAT YOU 

ARE A TRUE RENAISSANCE MAN. 

WRONG WHISTLER 

WHERE 13 01 

WRITE I HOPE YOU ARE JOKING. 
WRONG 

WHERE 13 01 

WRITE HINT - MONA LISA - HINT 

WRONG MICHELANGELO 

NEXT MREVIEW 



SLIDE 
ARROW 
ANS 



PAINTED THIS PICTURE - 
24 

1110 

LEONARDO 



ANS 



LEONARDO DA VINCI 
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This is a simple example, mainly intended to show the 
format of TUTOR statements; the full language has about 
7 0 verbs, called commands, and is functionally very rich, 
although syntactically it is at the level of assembler 
language . 

The verbs for answer evaluation specify words and 
characters which may or may not appear in a correct 
student response. Some spelling correction is performed. 
The verbs MUST, CANT, and DIDDL are used in the following 
example [Avner and Tenczar, 1969: command descriptions, 
DIDDL] . 

UNIT NURSE 

WRITE DIABETES IS A RESULT OF A MALFUNCTION 

IN THE . . . 
ARROW 1001 

ANS ABILITY TO METABOLIZE SUGAR 

MUST METABOLISM, UTILIZATION, BURNING, TOLERATION, 

METABOLIZE, UTILIZE, USE, BURN, TOLERATE 
WRITE VERY GOOD 

MUST SUGAR, SUGARS, GLUCOSE, GLYCOGEN 

CANT FAT, FATS, PROTEIN, PROTEINS, VITAMIN, 

VITAMINS, CELLULOSE 
WRITE YOU MUST BE THINKING OF A DIFFERENT DISEASE 
DIDDL ABILITY, CAPABILITY 



Each lesson has 63 variables to store integers, real 
numbers, and alphanume ic characters. The variables have 
fixed names, e.g., 12 3, A10 , and Fl . The partitioning 
of the 6 3 variables info the three data types is con- 
trolled by the author. 



2.3.4.2 The operational environment 

A student gains access to the system simply by typing 
his name. He is then resumed where his previous session 
finished . 

An author moves a work station into author mode by 
pressing the TERM key and entering a password. There are 
eight author commands , called options [Avner and Tenczar, 
1969: Chapter 9]. As TUTOR statements are keyed by an 
author, they are stored on disk, without any checking by 
the system. The READIN command initiates a batch compile, 
at the end of which errors are displayed. To correct 
errors, an author DELETE ? s the lesson just read in, issues 
the command EDIT to make his changes, and, having made them, 
he re-issues READIN. The system allows only one 
READIN request at a time; it is thus not a truly multiple- 
author system. 

2 . 4 Discuss ion 

2.4.1 Coursewriter is the only system which can be said to 
be production-oriented. If a CAI system is to deal with a 
large number of real students, with varying motivation, 
then it must do more than provide rudimentary facilities 
for student execution and course material preparation. 
To move from experimental to production status, a system 
should add facilities for: 
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( 1 ) regis t rat ion of students and maintenance of 
student records ; 

( 2 ) perf ormance recording ; 

(3) concurrent use by everal authors and several 
students ; 

(4) protection of instructional programs from 
tampering by students and authors ; 

( 5 ) minimizing the effect of system breakdown on 
user performance and attitudes . 

A fundamental point to recognize is that an instructional 
program is a non-terminating program. Thus the run-time 
environment of each student, which may require a large 
amount of storage for its representation, must be carried 
over from one s es sion to the next . The implicat ions of 
this pervade almost all aspects of the operational 
environment of a production system. 

2.4.2 All of the languages have neglected the power of a 
computer for character string manipulation for two 
significant tasks - presenting text and specifying answer 
sets. String manipulation is of course used in answer 
processing. The simple ability to name a character 
string would reduce effort when the same text message is 
used rapeatedly. Incorporating string expressions and 
operations, such as concatenation, in the language further 



reduces coding effort. Not only is effort reduced but run 
time efficiency and readability are enhanced. 

For example, in a PL/I-like language, if a character 
string variable named ANSIS has the value ! THE ANSWER IS 1 
then the display text statement 

DT ANSIS | | 1 BASE 1 

would print 

THE ANSWER IS BASE 

2.4-. 3 Instructional programs are continually being revise 
by their authors - during debugging of the first version 
and as feedback from students is received. Powerful 
editing and debugging facilities should therefore be a 
major part of the operational environment. Instead we 
find minimal editing facilities, and debugging often can 
only be done by signing on in student mode. If 
initiating an execution takes more than minimal effort and 
response time then an author will perhaps tend to spend 
his time visualizing what his program will do rather than 
seeing what the student will see. 

Most of the systems are typewriter based. The 
transient image of a CRT terminal allows more natural 
editing than a typewriter terminal. However, more could 
be done for the author using a typewriter terminal, e.g., 
context editors, than is being done. Moreover, the 
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distinction sometimes made between major and minor 
revisions is artificial. 

2.4.4 Inspection of source listings of instructional 
programs written in these author languages reveals many 
extraneous symbols and much unnatural syntax. Moreover, 
the languages do not conveniently illustrate the structure 
of lessons; FOIL is an exception in this respect. The 
properties of the underlying computer system or language 
translator often intrude upon the language. Examples are: 

(1) the subroutine linkage mechanism in Coursewriter 
is exactly the basic machine operation of 
branch and return on a register; 

(2) the @ symbol to denote the counters in 
WRITEACOURSE stems from a translator 
deficiency ; 

(3) labels are defined in FOIL by preceding the 
label identifier with the symbol : . This 
device is used to simplify the scanning algorithm 
of the trans lat or . 

(4) parentheses are not allowed in arithmetic 
expressions in TUTOR. This restriction simpli- 
fies the parsing algorithm of the translator. 
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2.4.5 Because new requirements in author languages are 
continually being identified, almost all of the language 
designers acknowledge the need for extensibility in their 
languages. Those existing systems which try to attain this 
do it in two ways : 

( 1 ) provide a linkage to subroutines written 
in some other language ( assembler in 
Coursewriter , FORTRAN in FOIL); 

(2) implement the language translator in a 
high-level language so that rewrites are 
more feasible . 

While (1) has the advantage that it does not disturb 
existing system code, it has the disadvantage that it 
involves an author in a language with which he is usually 
unf amiliar . Moreover , the syntax of a subrout ine 
linkage - CALL with a list of parameters - is not usually 
a natural syntactical specification. The second method 
has the disadvantage that some of the most intricate 
system code 5 namely the translator , has to be changed , 
and changed in an ad hoc manner. Neither method is 
satisfactory; what appears to be needed is 

(1) flexibility which allows extension naturally 
at the syntactical level 5 and 

( 2 ) a highly systematized implementation of the 
language trans lat or so that changes can be 
incorporated according to some formal model. 



CHAPTER 3 

THE DESIGN PHILOSOPHY UNDERLYING DIAL 



This chapter discusses the design philosophy formu- 
lated early in the project. 

3 . 1 M otivation 

3.1.1 The cost of preparing instructional programs 

The cost of preparing instructional programs is high 
- costs exceeding $100,000 for a one-semester course are 
not uncommon, for example [Hansen, 1969 3. The number of 
hours ^ author time to produce one (terminal-time) hour 
of course material is high. Estimates of 200 or more are 
reported [Bunderson, 1970]. A major part of this cost is 
due to extremely time-consuming iterations on the testing 
and revising phases in course preparation. One wants to 
reduce these costs. The effects on the total cost of 
each of the author language and the operational environ- 
ment for instructional programming have been separated 
for attack by the CAI System. 
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3.1.2 Difficulty of use of existing languages 

As can be seen from Chapter 2, the syntactic awkward- 
ness of existing languages and the clumsiness of command in 
existing systems make it difficult for an author to concen- 
trate on his main task, that of preparing instructional 
material . 

3.1.3 Lack of effectiveness of existing languages 

To be effective , the semantics of an author language 
should enable an author to use the unique capabilities of 
a computer. If these memory, file, and decision capabili- 
ties cannot be used, the resulting instructional programs 
are no different from conventional Programmed Instruction 
material and the systemc deserve the name "expensive page 
turners" given by Oettinger [1969]. 

3,1.4- Need for understanding of languages for man-machine 
systems 

Designing a language for CAI and the experience gained 
from evaluating it and its interactive programming environ- 
ment should shed some light on the more general problem of 
man-machine communication. Moreover, the system, once 
built, could be a valuable research tool for evaluating 
such languages if the language implementation admits of 
easy language modification. 
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3.1.5 Conclusions 

These motivating factors lead to two major require- 
ments - 

ease of use and modif iability . 

3 . 2 A priori design decisions 

3.2.1 The system should be interactive at course prepara- 
tion time 

The benefits of interactive, or conversational, 
programming are well known. This mode of programming is 
particularly economical when a program is being changed 
frequently. This is exactly the situation in CAI , where 
revision of course material is continually taking place 
as an author receives feedback from students taking his 
course . 

Moreover, by "seeing what the student sees" as he 
composes, an author is subject to the same restrictions, 
e.g., line length, response time, and noise, as his 
students . 

3.2.2 Authors will be experienced teachers 

This affects the quality of instructional programs 
more than the design objectives of DIAL. 
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3.2.3 Authors will be experienced computer programmers 

This is a major departure from the assumptions of 
most CAI languages. It is justified on two grounds: 

(1) pragmatically, it describes the situation of the 
first subject matter to be taught on the system; 

(2) constructing instructional algorithms is just like 
constructing other algorithms ; algorithmic technique 
cannot be avoided, and it is better and no more 
costly to learn it for programming in general than 
for just instructional programming. 

But the author inexperienced in computer programming 
is by no means excluded or ignored. Consider the follow- 
ing. 

(1) DIAL is meant to be a language simpler than a 
language of the complexity of FORTRAN. Its level 
simplicity should be comparable to BASIC. 

(2) An author, whether experienced in computer program- 
ming or not, has to learn the CAI-oriented features 
of a language which is new to him. 

(3) In trying to cater to the inexperienced, a language 
designer is strongly tempted to over-assist. However, 
an author preparing any non-trivial instructional 
program in any new author language, will soon get 
beyond the stage where assistance with language 

ERLC 
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mechanisms is needed. An author's facility in lining 
the language should not be underestimated. 
(4) There are well-known techniques for assisting 

learner* programmers , e.g., the default concept. 

3.2.4 Computer programming will be favor ^1 if a subject- 
matter- dependent des ign decision arises . 

3r2.5 The language should favor the tutorial mode of 
author-controlled CAI rathe r than dr ill -and - 
practice . 

3.2.6 The slide screen, rather than the CRT , will be th e 
main vehicle for the presentation of fixed textual 
information . 

Since color and graphic symbols can be used, the in- 
formation storage capacity of a slide is high. Note that 
this assumption obviat es the need for picture -drawing 
facilities in the language. 

3.2.7 The basic system approach is CAPI, not Question- 
answering . 

In an attempt to improve on the n intelligence" of 
existing systems as they appear to their student users, 
time was spent, and the temptation was strong to spend 
much more, on exploring existing experimental question- 
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answering systems. These systems have been built in 
research efforts in natural language processing and 
artificial intelligence [Simmons, 1970]. 

However, existing systems are indeed experimental 
and moreover have required major programming efforts to 
implement . So rather than follow this route, the decis ion 
was made to build a well - engineere d system , of less 
ambitious goals. With the generality of a programming 
language, the tools are provided for an author to produce 
intelligent instructional programs, 

3.2.8 There will be no coder for an author . 

I have observed in Coursewriter installations that 
placing a coder (sometimes called an instructional 
programmer) between an author and his instructional pro- 
gram generally results in programs that disappoint the 
author. Instructional programs are, by necessity, repre- 
sentations of algorithmic prcces ses . Too often in this 
environment, authors describe a concept to a coder and 
then vaguely define the instructional logic framework 
in which it is to be presented, without appreciating the 
algorithmic nature of the problem. For this reason I 
believe that an author must face, at first hand, the 
task of structuring his microscopic concepts . 



3.2.9 The work station will be CRT-based and fast. 



Terminal speed will be sufficient to fill the CRT 
screen in less than 5 sees (an 800 character CC-30 screen 
served by a medium-speed communications line 2400 bits 
per second — is filled in 2 1/3 seconds). An author 
language designed for a low-speed line (a teletype-speed 
line fills a CC-30 screen in 80 seconds) would have a 
different flavor . 

The terminal will be CRT -based, so if hard copy is 
needed 5 an auxiliary mechanism for providing it will have 
to be devised as part of the system. 

3.3 Objectives for the language per se 

3.3.1 First and foremost it s hould be a programming 
language . 

DIAL must be a language for describing algorithms. 
Thus it should 

allow symbolic names for entities manipulated, 
provide a subroutine facility 5 

have the statement types expected in algorithmic 
languages 5 

allow user-defined functions, and 
provide a library subroutine facility. 
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Although CAI workers differ greatly in their 
approach to using the properties of a computer, there is 
an agreed-upon requirement for providing individualized 
instruction . Thus there is the need for author tools 
for answer analysis and decision making (at the frame 
level and globally across a course). The need clearly 
emerges for the author language to have the generality 
of a programming language . 

3.3.2. Special CAI-oriented operators 

Because a theory of instructional program writing 
has not yet been developed , it is not possible to design, 
or even recognize, an optimal author language. There is > 
however, a generally accepted set of CAI-oriented commands 
and utilities. This set should be a part of any author 
language . 

Obviously, given the current level of understanding 
of the proces s of writing instructional programs , chi s set 
must be embedded in a very flexible system, which can 
adapt to a variety of different writing techniques. 

3.3.3 A general CC-30 display users l cM^uage, 

It is anticipated that there will be research 
(unrelated to CAI) at the University where there will be 
a need to write programs which use the CC-30. It would 
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thus be useful if DIAL could serve as a general display 
users language . 

3.3.4 Portability 

The system should be able to run on computer 
installations other than the University T s . 

3.3.5 Advan tages of a high level language 

Sammet [1969] lists the following six advantages: 
ease of learning; 

ease of coding and understanding; 
ease of debugging; 

ease of maintaining and documenting; 
ease of conversion; 

reduced elapsed time for problem-solving. 
My final design objective 5 which may appear to be obvious 5 
is that these advantages of a higher level language will 
in fact exist in the final product. 



3.4 Objectives for the interactive programming system 

The operational environment has as much bearing on 
ease of use for an author as the language itself. The- 
chief components are the command language and its 
implementation . 



The design objectives for these are as follows. 
An author should not be aware of the translation from 
his DIAL statements to machine language. He should 
feel as if he ds programming a "DIAL machine", that 
is 5 a machine which directly executes his statements 
without the need for translation. 

The CAI System , while in author mode , should at every 
step try to anticipate an author ? s next move and 
position the CRT cursor accordingly. 

The language processor should be an incremental com- 
piler, not just a fast batch compiler entered 
interactively. The system could then maintain a 
consistent response time even when changes to 
existing source are made . 

When the known properties of the language, environment, 
and application dictate system actions that are 
normally user-specified in a general-purpose system, 
the CAI System should handle them automatically. 
Diagnostic messages given by the system should 
specifically identify the location and type of errors, 
not j us t s ignal that an error has o ccurred . 
The CAI System should be responsive to the experience- 
dependency of an author. For example, the explanatory 
level of diagnostics given him should decrease as he 
becomes more familiar with the mechanisms of using 
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the system. 

3.5 Why not adapt a general purpose programming language? 

The notion of adapting a well-proven general purpose 
programming language, such as PL/I, APL, FORTRAN, BASIC, or 
CPS, was not rejected casually. 

For this discussion, the term bas e language describes 
the general purpose language, and the term CAI language 
describes the base language augmented by a set of CAI - 
oriented routines. 

The advantages of adapting a base language include 
the following. 

1. I would not need to write a compiler. Obviously, the 
routines making up the augmentation must be written, 
but the programming involved is generally easier than 
compiler writing. 

2. The users of the system would have a well-proven im- 
plementation without compiler maintenance 
responsibilities . 

3. A large body of subroutines written in the base 
language would be available. 

4. Authors who knew the base language may take less 
time to learn the CAI language. 

5. One would have the generality argued for in section 
3.3.1. 
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In my opinion > the advantages are outweighed by the 
following disadvantages . 

1 . De f iciencies in the base language 

This impacts writing both augmentation routines and 
instructional programs in the CAI language. Input/output 
facilities are not oriented to terminals 5 particularly 
CRT's. The absence of file input/output in APL is a 
severe deficiency. APL and FORTRAN do not have good 
string handling facilities. 

2 . Deficiencies in - the base la nguage implementation 

If the base language is not interactive then one is 
faced with conversion. The systems programming effort 
required to convert a base language batch compiler to an 
interactive incremental compiler would probably be as much 
as that required to build a compiler for a new author 
language . 

Because the ratio of execution to modification is 
high 5 one needs compilative execution to give fast 
response and low cost for student mode. However 5 most of 
the interactive implementations are interpreters . 

3 . The operational environment is compromised 

If there is an interactive implementation of the base 
language available 9 e.g., APL/360 or CPS-PL/I 5 then there 
is an opportunity to use its command facilities for the 
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CAI application- But then instructional programs are just 
like any other programs in the system - a student must 
load, initiate and terminate a program just as an author, 
or any other user, does. Other activities, such as student 
record file processing, performance recording, dumping 
against system failure, and proctor actions, must also 
be handled within the existing framework of the host en- 
vironment. My design philosophy requires an integrated 
system serving students, authors , and proctors. This 
cannot be achieved with the general purpose interactive 
systems available to the project. A special purpose sub- 
system must be built or the desired operational environ- 
ment compromised . 

4. Overhead 

The base language would contain many language 
features which would never be used by an author. The 
overhead which results would be felt mainly at compile 
time, as extra memory space and response time when 
compiling in author mode. This effect is relatively 
small . 

5 . Difficulty of use 

Invoking the special CAI facilities, in most 
languages 5 would be done by a CALL statement. 
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This not only adds superfluous code in an instruc- 
tional program, which can cause readability to deteriorate 
but, more importantly, the syntax of the CAI language is 
awkward to the CAI user. For example, 

CALL RESUME; 

CALL FRAME; 

CALL SHOWAS (Note | | 'The variable has been used 
before . 1 ,A,B) ; 
• 

CALL MATCH (PATC'CDO t = <f 1 ) , PAT ( X | | Y) , X||Y,L); 

Not all base languages , however , require invocation 
by CALL. APL has the cleaner function invocation, but 
parameter passing is awkward. PL/I also has user- 
defined functions 5 but a function is invoked by the 
appearance of its name in an e xpression. This will, for 
some operations, result in unnatural syntax at the 
invocation point. Consider a user-defined function for 
reading . One would prefer to say : 

READ; 

but the function name must be in an expression, so one 
is obliged to say : 

ANSWER = READ; 
For control structures, e.g., REPEAT-UNTIL and UNREC 
in DIAL, even more additional codf-: is needed in the form o 
labels and GO TO statements. 



The macro pre-processor of l'L/1 ( Lhe "compile- 1, i 
facilities") does provide a solution - a pre-processor pa 
could substitute correct PL/I syntax for user-oriented 
syntax. However, when the design decision was made there 
were no production-status interactive systems providing 
the macro facility. 1 Moreover, user errors would not be 
detected until the PL/I translation stage. 

My reasons for not adapting a general purpose lang- 
uage can be presented another way. Those requirements 
for a base language and its implementation which would 
make adaptation my preferred approach are : 

(1) the base language to be PL/I; 

(2) the availability of a good incremental 
compiler; 

(3) a well-designed command language for the 
incremental compiler ; 

(4) the availability of the PL/I macro facility 
for implementing the CAI specialized operations 
with most natural syntax; 



Since that time, TSO , the Time Sharing Option of 
Operating System 360 with the MVT configuration, has been 
announced and is available at TUCC. However, it presents 
the same problems for the CAI application as do APL and 
CPS: the operational environment would be compromised. 
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(5) the operating system to contain a user inter- 
face language allowing a user program to execute 
system commands within a program. As an example 
of the f unction , not the syntax, needed, con- 
sider an APL program (which is not in fact valid 
in APL/360) : 
V CAI 

STUDEMTAID «- □ 

STUDENTAWS «- SEARCH STUDENTAID 
) LOAD STUDENTAWS 

• 

NEXT: EXECUTE 

SAVEACOUNT + SAVEACOUNT + 1 
■»■ (SAVEACOUNT < 3) /NEXT 
)SAVE STUDENTAWS 
SAVEACOUNT + 0 
->MEXT 

• 

V 

With such a facility one would be able to layer 
the CAI command language on top of the inore 
general, and hence complicated, command language 
of the base language 1 s operational environment. 

ERJC 



CHAPTER 4 
THE DIAL LANGUAGE 



4 . 1 Introduction 

This chapter describes the author language itself; 
the command language used by an author while interactively 
programming in DIAL at a work station is covered in 
Chapter 5. Hence this chapter specifies the language in 
which an author writes an instructional program, which is 
independent of whether he programs interactively or in 
batch mode from cards were such a facility provided. 
Another reason for separating the descriptions of DIAL and 
the command language is that DIAL is the variable part 
changes in the language are implemented by the Translator 
Writing System described in Chapter 6. 

Layout of the chapter 

Since this chapter is intended to serve as a guide 
to using the language, a set of language specifications 
alone would be inadequate . The development of the chapter 
is as follows. Section 4.2 presents enough of DIAL to 
allow complete programs to be written, but with the 



simplification that all student answers are recognized by 
exact matching. The remaining sections gradually introduc 
the full facilities of the language. 

The last section, 4.16, DIAL specifications, is a 
summary of DIAL and can be used for reference purposes by 
authors experienced in the language . 

Since the chapter aims to help a prospective author 
learn DIAL, rigor is traded for clarity in some sections. 
The specifications section, however , is rigoz^ous . 

A DIAL machine 

The design of the language and its operational 
environment is such that an author can take the view 
that he is programming a ,! DIAL machine. 11 This machine 
directly executes DIAL statements without the need for 
translation. Thus, as a policy, this chapter avoids 
referring to the compiler for DIAL. 

Color messages 

The CRT can display characters in green, red, blue, 
or yellow. This useful facility enables an author to 
highlight portions of a CRT message and provide color 
cues to message content. Because color selection is done 
in the operational environment , not the language , it is 
not treated here. 



5 5 



4 . 2 Writing a simple instructional program 

Consider the following segment of an instructional 
program dealing with logical operations on bit strings : 



i 



1 SHOW 'If the bit strings B and C contain 

110 and Oil respectively, what is the 
value of A after the execution of A=B£C? ' 

2 BACK: MATCH '010', OK 

3 MATCH '111', NOK 

4 SHOW 'Wrong, try again.' 
-5 GOTO BACK 

6 NOK: SHOW 'No. By definition 0 £ 1 is always 0 

Your answer is correct for A=B|C. 
Try again. ' 

7 GO TO BACK 

8 OK: SHOW 'Right. ' 4 
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Example 4 . 1 



Statement 1 presents a question by displaying the 

text 

If the bit strings ... of A=B8C? 
on the CRT ; statements 2 and 3 specify the student 
responses anticipated, together with the actions to be 
taken for those responses. Thus, if the student answers 
010 the program branches to the statement labeled OK 
which displays 'Right. 1 

Statements are the units of operation within the 
language. They will normally be executed consecutively as 
written. However, this sequence of operations may be 
broken by branching statements. The MATCH and GOTO 
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statements in Example 4.1 are branching statements. A 
statement may be optionally prefixed by a label, as 
statement 6 is. 

Identifiers^ or names, are created by an author to 
identify program units in a DIAL program. They have no 
inherent meaning but serve for the identification of 
variables, labels and subroutines. An identifier is a 
sequence of upper or lower case letters and digits, not 
exceeding ten characters, beginning with a letter, e.g., 
X CI cardformat BACK clw2 

Only identifiers for labels occur in Example 4.1. 
An identifier naming text, for example, could be R, and so 
if R had been set previously in the program by the 
assignment statement 

R <- 1 Right, 1 

then the statement 

OK: SHOW R 

would be equivalent to statement 8 in Example 4.1. 

DIAL statements are free form. Blanks may be used 
freely throughout a statement. A blank is needed to 
separate two tokens in a statement if there is no other 
delimiter which the DIAL machine can use to determine the 
separation. For example, X+Y is equivalent to X + Y but 
GOTOBACK is not equivalent to GOTO BACK. Any number of 
blanks may appear wherever one blank is allowed. 
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Composite operators, e.g., <- and -> = cannot contain blanks. 
Unrecognized responses 

In the example, only the responses 010 and 111 are 
recognized. Thus, by the program sequencing rules, any 
other response will cause statements 4 and 5 to be 
executed, (with the possibility of a continuous loop: 
2, 3, 4, 5) . 

The UNREC statement is a branching statement 
specifying prograin action in case unrecognized responses 
are received. The format of this statement is defined 
using the notation (Figure 4.1) to be used from now on. 

UNREC-statement : 
Format : ^ 

UNREC label C, label] . . . 
Action : 

t h 

The i unrecognized response to the controlling 

t h 

SHOW-statement will cause a branch to the i 
label in the UNREC label list. 



In this chapter, the first time a statement is 
presented, usually an abbreviated fovm will be given. 
For example, the symbol * can be an item in an UNREC 
label-list. The chapter progressively develops the 
full format for each statement. 



58 



A uniform system of notation is used to define the format of each DIAL 
statement. The notation is not a part of DIAL', it is a metalinguistic device 
to describe the structure of DIAL statements and can be used to describe most 
programming languages. It indicates the order in which the elements may (or 
must) appear, the punctuation that is required, and the options that are 
allowed. The notation is a subset of that used in IBM PL/I publications 
[IbM 1970b, Section A]. 

A notation variable names a general class of elements in the language, 
e.g., label, text-constant, frame-name, and is one of the syntactic units. 
Other syntactic units are DIAL verbs, e.g., UNREC, punctuation, e.g., a 
comma, and special characters, e.g., +. 

Syntactic units are combined by juxtaposition, braces, and square 
brackets as follows. 




vertical stacking of syntactic units indicates that a choice 
is to be made, e.g., 




DCL identifier 




square brackets denote options. Anything enclosed in brackets 
may appear one time or may not appear at all. For example, 



F>JDLESSON [lesson-name] 



indicates that a lesson-name is optional in an ENDLESSON statement. 



three dots denote the occurrence of the immediately preceding 
syntactic unit one or more times in succession. For example, 



[, label] . 



A label preceded by a comma may or may not occur since it is 
surrounded by brackets. If it does occur, it may be repeated 
one or more times. 



The following example contains each part of the notation. 



[label:] MATCH text-constant [| text-constant] . 




Valid MATCH-statements are 



d2w: MATCH 'alpha 1 | r 
MATCH 'alpha 1 , k3 



'beta 1 | f gamma f , 



A 



Figure H.l - 



- The metalanguage used to define the syntax of DIAL. 



UNREC L1,L1,HELP,ANS1 

This will cause the statement labeled LI to be 
executed after both the first and second unrecog- 
nized responses are received. The statements 
labeled HELP and ANSI will be executed on receipt 
of the third and fourth unrecognized responses, 
respectively . Example 4.2 ( statement 4 ) shows 
this UNREC-s tatement embedded in a program segment. 



1 




SHOW 


Q 


2 


BACK: 


MATCH 


' 010 ' ,0K 


3 




MATCH 


•111' ,N0K 






UNREC 


LI , LI , HELP, ANSI 


5 


LI : 


SHOW 


'Wrong, try again' 


6 




GOTO 


BACK 


7 


HELP: 


SHOW 


'Wrong' , LOGIC4, 








'Now try again ' 


8 




GOTO 


BACK 


9 


ANSI: 


SHOW 


'No. The answer is 010 


10 




GOTO 


NEXT 


11 


NOK: 


SHOW 


Bl 


12 




GOTO 


BACK 


13 


OK: 


SHOW 


' Right . ' 


14 


NEXT: 





Example 4 . 2 



QAR s c re en divi s ion 

The CRT screen is divided conceptually into three 
areas: Question, Answer, and Response: 
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Q 



A 
"R 



The Q-area is filled by one or more SH0W ! s presenting a 
question. When a MATCH is encountered, the cursor is 
placed at zhe beginning of the A-area for the student to 
enter his answer. The author's feedback response appears 
in the R-area and the cursor is then placed back in the 
A-area so inviting the student's next attempt. The 
student edits his previous answer using the inherent 
editing properties of the CRT. 

For Example 4.1, if the student first entered 111, 
the screen would appear as 

If the bit strings B and C contain 
110 and Oil respectively, what is the 
value of A after the execution of A=BSC? 

Ill 

No. By definition 0 £ 1 is always 0. 
Your answer is correct for A=B| C. 
Try. again .... 
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Showing slides 

As well as displaying text, the SHOW-statement shows 
slides; for example 



would, if nesteddo is an identifier naming a slide 
variable rather than a text variable, show that slide 
number to which nesteddo is currently set. 

The format for the SHOW-s tatement so far in the 
development is 



Slide variables can be set by assignment-statements; for 
example, 



would cause SHOW nesteddo to show slide number 7 in 
:arousel 23. 

Comments 

Comments are enclosed between the markers /* and */ 
and may be placed anywhere in a DIAL program that a blank 
is permitted. Any characters may be used in a comment 
except the pair */, which ends the comment. Comments are 
completely ignored by the DIAL machine, but their use 



SHOW nesteddo 




Example : Line 7 of Example 4.2. 



nesteddo <- 2 3 07 



adds to the readability of an instructional program. 
Declarations 



Two types of variables have been discussed - the 
slide variable and the text variable. Notice that an 
identifier naming a variable has the same formation 
rules whether the variable is slide or character, but 
its interpretation in 5 for example, a SHOW operation 
will be different. Thus the system must know whether 
it is to show a slide or text. 

This property-designating information comes from 
associating an attribute with each variable. A variable 
is given an attribute by one of the two following means. 

(1) An author specified declaration 

A declare statement is used. 
Format : 

DCL identifier attribute 

Examples : 

DCL nesteddo SLIDE 
DCL Q TEXT 

A DCL^statement may appear anywhere in a lesson as 
long as it appears before the first use of the identifier 
it names. 
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Other attributes are introduced in later sections of 
the chapter. 

(2) A default declaration 

Unless an author specifies an attribute for a 
variable, it is assumed by default to be TEXT. 

A complete program 

Brief consideration for the operational environment 
is all that is needed now to write a complete lesson. The 
lesson must be named so that an author can refer to it in 
the CAI System. This is done by the )LESS0N command; 
since Chapter 5 discusses the command language, it will 
not be treated here. 

The action to be taken by the student at the end of 
a lesson must be specified. This is done with the 
ENDLESSON statement. 

Format : 

ENDLESSON [lesson-name] 

Action : 

The following system message is displayed. 
END OF LESSON 

DO YOU WISH TO GO ON TO THE NEXT LESSON? 
TYPE YES OR )0FF 

The last statement executed in a lesson must be 
this statement . 
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A set of lessons constitute a course and a student 
takes the course lessons in sequence. The simplest 
complete program, then, is a one-lesson course and 
Example 4.3 shows such a program. 



1 /* An example of a complete program */ 

2 DCL logics SLIDE 

3 logic'4 <- 2301 

4 SHOW 'Message 1 , logics 

5 ENDLESSON 

Example 4.3 

4 . 3 Defaulting branching in a program 

Many programmed actions are repetitive, e.g., the 
action of displaying 'Right. 1 and branching to the next 
part of the course material to be presented. The DIAL 
default ^actions help an author by allowing him to 
indicate that he will take the default action and so 
need not explicitly prograjn an action himself. 

To take advantage of the default branching it is 

necessary to give the system some help; an author has to 

2 ... 
put a little more structure on a lesson by organizing it 

o 

This is more structure than usually found in 
programs written in a general-purpose programming 
language, but is the norm for computer-assisted 
programmed instruction. 
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into frames . A frame is a logically self-contained part 
of a lesson enclosed by 

frame-name: FRAME 

and 

END f r ame -n ame 

where frame-name is an identifier. The DIAL statements in 
a frame are usually ordered to give the following structure 

frame -name : FRAME 

present textual information 

pre s e nt que s t i o n 
> accept answer 
1 class if y answer 
T- respond according to answer 
END frame -name 

All defaults actions are requested by the symbol * as 

follows : 

MATCH-statement 

Example : MATCH T 010 ; 5 * 

Action : If the match is successful then 

(1) the system displays f Right. ! in green, 

(2) the program branches to the next 
frame . 



°Note that this is the only part in the language in 
which the "correct answer" has any significance. Some CAI 
systems give additional special treatment to the correct 
answer, e.g., an author can mark a particular text as being 
the correct answer for later automatic display if the stu- 
dent fails the question. Although the distinction is use- 
ful, I believe that the important distinction is not 
between correct and incorrect responses , but between 
recognized and unrecognized responses. 



on slides and CRT 



class if icat ion 
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UNREC- statement 

Example : UNREC *,*,L 

Action: for each default label: 

(1) the system displays the UNREC message 

in yellow. This message reads 

Your answer was not recognized. It may 
be wrong, or it may be right in content 
but wrong in form, spelling or punctua- 
tion. Examine your answer and try again. 

(2) the program branches back to the first 
MATCH-statement (the lead MATCH) of 
<.he controlling SHOW-statement . 

GOTO -statement 
Example : GOTO * 

Action : The program branches to the next fram. 

Example 4.4 shows the program segment in Example 4.2 
recoded using the default sequencing facility. 



BACK: 

HELP: 

ANSI: 
NOK: 



SHOW Q 

MATCH * 010 * ,* 
MATCH ' 111 1 ,N0K 
UNREC *,*, HELP, ANSI 
SHOW 'Wrong' , L0GIC4 
'Now try again' 
GOTO BACK 

SHOW 'No. The answer is 010" 
GOTO * 
SHOW Bl 
GOTO BACK 



Example 4.4 
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4- • 4 Classifying recognized responses 

Since, for the branching purposes of a particular 
question, several responses may be equivalent, it is 
natural to allow more than one argument in a MATCH- 
statement. The definition of the MATCH-statement is now 



MATCH 



variable 
text-const 



| variable 
I text-const 



label 



If at least one of the specified texts in the list matches 
the student's answer, then the program branches to label 
or takes the default action if * . Examples are statements 
3 and 6 of Example 4,5. 

Thus classification of recognized responses for each 
question, takes the form; 



MATCH t ±1 | r 12 
MATCH r 21 | 



, label-1 
, label-2 



MATCH r ml | 



label -m 



, , . th j , , . th 

where r. . is _ che i recognized response m the l 
i ] 

equivalence class. The vertical bar separator between 
arguments is to be read as or. 
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1 Q <~ ; Write an expression which means 

"multiply A by B and assign the 
result to C" f 

2 LI: SHOW Q 

3 MATCH ! C = A*B } I >C = B*A ! , OK 

4 UNREC ^ ,L2 5 REMED /*0:i the third, go see what */ 

/-help he needs */ 

5 L2 : SHOW 1 No . Type the. two variables being 

multiplied ! 

6 MATCH ! A B ! | 'A 5 B ! j 'B A' | ! B 5 A ! 5 NX 

7 GOTO REMED /^Unrecognized, so go */ 

/*see what help he needs * I 

8 NX: SHOW 'Yes. Multiplying them would 

be achieved by A*B. Try the 
que st ion again ' 

9 GOTO LI /*Back to original question */ 

10 OK: /* Present alternative correct answers: */ 

11 SHOW 'Yes. C = B*A and C = A*B 

are both right . ' 



17 REMED: 



Example 4 . 5 

4 . 5 Expressions and assignment statements 

We have already encountered the assignment statement - 
a value is assigned to the variable or the left hand side 
However, in the examples so far, t/ia right hand side 
contained only one item. It is possible to construct an 
expression on the right hand side containing several 
items (variables and constants) with operational symbols 
(operators) linking the items. For example 

Y <- A + B 
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is an assignment statement which upon execution wil] 
cause the expression A+B to be evaluated and its valve 
assigned to Y. 

The express-. Lot is an arithmetic expression. 

Other expressions in DIAL are text, slide, logical, and 
comparison expressions. The items combined by operators 
are called operands. Operators can only act on operands 
of the same class, i.e., arithmetic operators can only 
act on operands with the attribute INTEGER. 

Examples : 

(1) a text expression using the concatenation operator: 

a | | ! Dog r | |b 

( 2 ) An arithmetic expression : 

a*(b + c) 

(3) A slide expression to add one to the slide variable 
THM: 

THM + 1 

The two classes of expressions called logical and 
comparison result in truth values and are discussed in 
later sections . 

A complete definition of DIAL expressions is given 
in the specifications . 

Expressions are not restricted t ^ assignment state- 
ments; a new rule is now introduced: whenever text can 

O 

ERLC 
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appear in a statement , a text expression may appear. 
So v 7 c have 

MATCH A | |B, L5 

and 

SHOW a | | 'Dog 1 | |b , THM 
Vhe general format of the assignment statement is 

ftext-expr 
slide-expr 
arith-exp 

Examples : 

L5: REPLY <- ANSIS | | ? Dog T 
SCORE <- A * B + 7 
I <- I + 1 



4 . 6 The IF-statement for branching 

The MATCH-s tat erne nt is a branching statement which 
applies tests to the ANSWER register. With the IF-state- 
ment, much more general tests can be applied. For 
example 

IF QCOUNT > 3 THEN SHOW Rl 
SHOW R2 

compares QCOUNT with 3. If the former is greater, i.e., 
the teat is successful, then the statement SHOW Rl is 
executed and then SHOW R2 . If the test is unsuccessful, 
SHOW Rl is skipped. 
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Tests to be performed are specified by a comparison- 
expression. QCOUNT > 3 is such an expression. Its 
evaluation results in a truth value (1 = true, 0 = false). 
The format of the IF-statement so far is 

IF compards on-express ion THEN statement 

It is sometimes convenient to specify a group of 
statements to be executed if a test is true. For DIAL, 
statements can be grouped into a DO-group by using the 
DO and END, e.g. , 



In a second, irore general form, the IF-statement 
controls the execution of two alternative statements. 
The simple IF-THEN clause is expanded by the ELSE-clause. 
If present, it always follows after* the THEN-clause . 
For exairple , 



The THEN-clause is executed only if A > 2 is true; the 
ELSE-clause is executed only if A > 2 is false. As with 
THEN, a DO-group may follow ELSE. 



X<-X+l 

SHOW R2 
SHOW R3 
END 



The format of the IF-s tatement is now : 




IF A > 2 THEN X <- Y 



ELSE X < 



- -Y 
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Since the comparison-expressions have truth value 
they can be combined by logical operators which take 
truth values as operands . Thus 



Typical uses of the IF-statement 

(1 ) For structuring instructional logic 
a. At the frame level 

IF LENGTH (ANSWER) > 10 THEN LJTl- REM 4 
"b. Globally in a lesson 

Let BADCT be a score kept throughout a lesson 
and PATH 2 an integer set to 1 or 0 to indicate 
whether a particular path was taken. The 
following statements specify branching based on 
the variables BADCT and PATH 2 . 



(A > 3) | (B < 5) 



is a logical - expression . 



The formal now becomes 




IF (BADCT>25) S (PATH2=1) THEN DO 

SCALE 4 <- SCALE4 + 1 

/ * Increment performance */ 
/"measure. */ 
GOTO LAB7 / -'-Remediation */ 
END 

ELSE GOTO L5 

/'''continue in main */ 
/* stream. ' */ 

(2) For general programming. 

a. At: "che micro level 

/''•'Remove the first occurrence of */ 
/"the substring AND from the */ 
/ "ANSWER register : - */ 
J <- INDEX (ANSWER, 'AND 1 ) 

IF J -i= 0 THEN /-If J=0 then was not in ANSWER */ 
ANSWER <- SUBSTR(ANSWER,1,J-1)| | SUBSTR (ANSWER, J+3) 

b. Loop control 

/*Loop to show the first 20 slides 5 ' ;/ 
/"in carousel 15 : - ••'/ 
DCL SL SLIDE 

SL <- 1500 /^Initialize */ 
>L1: SL <- SL + 1 

A IF SL > 1520 THEN GOTO EXIT 

SHOW SL sw 
GOTO LI Y 



EXIT: ^_ 



Nesting 

IF-statements can be nested, for example 

IF A + B THEN 

IF X = Y THEN Z <- 0 

ELSE Z <- 1 

EL ,E 

IF X > Y THEN P <- 0 

ELSE P <- -4 



m 

Finally, note the equivalenr-j of the following two 
statements . 

MATCH T ALPHA * | 1 BETA 1 , L5 

IF ( ANSWER^ 1 ALPHA 1 ) j (ANSWER= 1 BETA 1 )THEN GO TO L5 
The MATCH-s tatement is an abbreviated form of an IF- 
statement with the ANSWER register as an implied 
comparand . 

M- . 7 Non-exact mat c hing 

To confirm the need for some assistance in 
recognizing responses, consider the problem of answer 
processing for the question "What is the name of the UNC 
student newspaper?" The responses 

T Daily Tar Heel f , 1 Daily Tar Heel 1 , 'DAILY TAR HEEL', 

'The Tar Heel 1 , 'The TAR HEEL 1 , 

1 DAILY TAR Heeel', and 1 DAILY Gazette 

can all be viewed c=.s correct, except for the last one. 

Restricting answer classification to exact matching would 

obviously place an intolerable burden on an author, no 

matter how carefully he phrased his questions. 

With the simplification (Chapter 3) that sophisticated 
linguistic analysis of responses will not be provided in 
the current phase of the CAI Project , the problem of non- 
exact matching is left mainly to the ingenuity of the 
author. The approach taken to help the author combines 



(a) the provision in DIAL of system-matching-f unctions 
(smf T s) and (b) requiring the author to observe certain 
conventions. 

The conventions apply to message preprocessing a 
student's typed response always goes through a preproceijso 
before ANSWER is filled. The prepiocessor 

(1) strips preceding and following blanks 
surrounding a typed response, and 

(2) squeezes excess blanks between non-blank 
characters . 

This preprocessing always occurs. To deal with the 
uppercase -lower case problem, the DIAL machine T s 
preprocessor has a switch named CASE which, when on, 
causes all lower case letters in the response to be 
converted to upper case as ANSWER is being filled. 

Thus while CASE is on, matching will not distinguish 
between upper case and lower case if MATCH-statement items 
are written in upper case. For example, 

MATCH ! THE TAR HEEL f | 'DAILY TAR HEEL ! , hi 
would, with CASE switched on, recognize all but the last 
two in the example. 

CASE is set by an assignment statemei: 1 : 
CASE <- arith-expr 
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for example , 

CASE <- 4 
CASE <- 0 

Thus although CASE stores an integer it ha3 only two 
states, namely, cm if its value is non-zero; off if zero. 

A second preprocessor switch, called SQZ * squeezes 
all blanks from a typed response. 

System matching functions 

The smf 1 s are PAT for pattern matching against the 
ANSWER register and PEN for using the light pen. The 
latter is detailed in a later section . The smf 1 s return 
a truth value and hence are (one-item) logical expressions . 
To effect branching based on the values returned, smf 's 
can appear in MATCH-statement s and IF-statements . 

The PAT smf uses the pattern specified as its 
argument and searches ANSWER for the occurrence of that 
pattern. A pattern is ,~ade up of a sequence of pattern 
elements separated by a cent symbol, the "don ! t care" 
.symbol, where any number of noise symbols may appear. 
For example, PATC ' 1 ) would be true if ANSWER con- 
tained ALPHA * BETA + D. 

By making answers to questions of the type "Give an 
expression which nultlplies two variables" rather than 
"Give an expression which multiplies A and B" quite easy to 

O 
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process, che PAT function should encourage an author' t.o 
go from the specific to the general in his questioning. 

Because PAT is quite general it covers s irppler 
functions often found in CAI languages. Keylett er and 
keyword matching are two examples . Keyletter matching 
is intended to cope with spelling errors in a student 
response. For example, 

; J MATCH PAT ( f tIDENTtFtRt 1 ) , L5 
would cope with certain misspellings of the word 
"identifier. 11 

All correct answers , except the last , in the Tar 
Heel example would be recognized by the keyword matching 

PAT ( ! tTAR HEELC ! ) 

if CASE is on. 

Note tha^ the text function INDEX can also be used 
for keyword matching. 

Notice also that PAT has an implied or lering by the 
order of the pattern elements. So the following two 
segments are equivalent : 

(1) MATCH PAT ( ! tTARCHEELt ! ) 5 LI 
GOTO L2 

(2) J <- INDEX (ANSWER 5 ! TAR ! ) 
K <~ INDEX (ANSWER , ! HEEL ! ) 
IF J=0 | K=Q THEN GOTO L2 
11? K > J THEN GOTO LI 
GOTO L? 



4. 8 The sieve 

Shortly after Brooks began to. use DIAL (Chapter 7) 
he invented the sieve; it was made possible by the PAT 
system matching function. 

Figure 4.2 gives an example. The actual sieve is 
contained in statements 224 through 2 50* 

The sieve consists of an ordered set of expected 
responses. The first is correct; each successor allows 
one more erroneous element, or conversely requires one 
fewer correct element. The responses are arranged in 
order of increasing seriousness of error. 

An answer falls through the sieve until it 
encounters the first response that requires no more 
correct elements than the answer has. 

The feedback for each response ic designed to teach 
about precisely the error that distinguishes that 
response from the one above it, and it always requires 
that the student try again. 

This correspondence, between feedback and sieve level 
works properly for several reasons. Falling through to 
thp.t level means the student surely made at least the 
error addressed. Falling no further means he made a no 
more serious error . The ordering means that the error 
addressed is the most serious one he made , however many 
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200 d2: 

PFSUHE ; 

202 CA5EOPF; 

?0U s don, CLfiAP; 

2Pd PINT; 

2M : 

210 ; 

220 SAS CL5AR, 

•Write a statement labeled 5 AH that will 



iterate the grouv ot stateacnts it 
controls SO tiroes. Use the variable X 



as yoi - index, ' ; 
2 2U dJro: « 1 SAM : DO X = 1 TO 50;',t2E; 
22H H •SA«:DO X=1 TO 50', 42*1; 

210 M P { • S AM : DO X = 1 TO bC * ■ ) , 

d2v1a; 

r. P J,T{ • SAtt«DO x = 1 TO 50*»)# 

d2u2; 

M PAT('*DO X=1 TO *>0r») ,d2w 3; 
M PAT(»*DO X=1 TOtf'),d2vU; 
M PAT( • £D0 X = 1 * •) , d2w5; 
M PAT(»*DO X = *») ,d2u6; 
M PAT( 1 tDOt 1 ) , d2w7; 
U *; 
SAS 

•Your statement should contain DO.',t; 
2SU r,OTO d2n; 

256 d^w1:S nq,f orqotsemi r t; 

257 GOTO d2o; 

26H <!2w1a:S extransq,t; 
2V) GOTO d2u; 

260 d2«2 : SAS 

•A colon should follcw the label.', t; 
262 GOTO d2n; 

2hi\ d2wJ:SAS 



21/ 

2 i 

2U0 

2U4 

2U6 

2Ud 

250 

252 



2n6 GOTO d2m; 

26 H d2w<4: SAS 

•Th* upper liait of the iteration count 

.should he 50. 1 ,t; 
270 (TOTC d2»; 

2 72 d2wV. SAS 

•The *ord TO separates the starting and 

ondin'j values of the iteration count. 1 , 
t ; 

27U GOTO d2m; 

2 76 d2*b;SAS 

'The iteration count should start with 1 
• , t; 

2 "7 GOTC d2a; 

27H d2w>:SAS 

•Tht» iteration ccunt expression should 



heqin 



2 BO 

2H2 d2r 
400 ; 



GOTO A 2b; 
5 r; 
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i npec 



1. DIAL VPKB ABRRFVI ATIONS : 



TEXT COV" TANK'S NA- ur n PAPI.IFK 'V 
THE PROGRAM: 



ext ramsg 



forgotsemi 



'You have enteroH sopit-l' 1 { pp 'n 
Addition to or instead of thr 
semicolon vhlch should nnd a 
PL/C statement.' (Mup) 

'You forgot the semicolon. 1 
(blue) 



'Nor. ntHte. 
'UipHt. ' 
'Trv again. 



(vp 1 low) 

(green) 

(red) 



don is slide 1.51, named earlier in thn 
program, It is shown <n p iguro 

PINT, a temporary addition to 0 1 A I, (see 
8.3.3.2,2), displays "Press IN"*" to ror.tinun 
when ready." and thp.n waits f or J*? T . 



rij»ur« l \ .'i A DIM, program siojvno.nt showing, a :;.u;v<? for rinuwi't- «;vuluat i'»n 
Ti the expected response SAM*. DO X=l TO SO; 
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others there may be . Trying again means the errors are 
all treated 5 one at a time. The result is an analyzer 
whose length and complexity grows linearly with the 
number of anticipated errors , but which is capable of 
handling all combinations of them. 

Progressive teaching also results from this ordering 
of the sieve elements. If the student has no idea what the 
answer should be he will be led, step by step, through the 
construction of the right answer. Such a trace of the 
sieve in Figure 4.2 is: 



Sieve element 
MATCHed (DIAL 
Student Response statement #) 



Feedback 



(null) 
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(UNREC message) 



(null) 
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Your statement should 
contain DO . 
Try again. 



DO 
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The iteration count 
expression should 
begin 



X= 

Try again. 



DO X= 
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The iteration count 
should start with 1. 
Try again. 



DO X=l 



4 . 9 The naming statement 

The assignment-statement of Example 4.5 assigns a 
text constant value to the variable Q. This is a useful 
technique when a particular text is to be used repeatedly, 
as it saves rewriting the complete text each time. There 
is a DIAL statement solely for this naming function, 
which uses = to indicate identity rather than < - which 
is used to indicate setting of a variable value. 

Forma t : 

identifier = text- const 
Examples : 

c bs = 'Observe the slide above. 1 
pint = 'Press INT to continue. 1 

When an identifier is so used, it is given the TEXT 
( constant) attribute . 

Variables, by definition, require the DIAL machine 
to keep a separate copy for each studen . In contrast, 
when an author uses a naming-statement he is signalling 
that the identifier is a name, not a variable-name. Hence 
only one copy is needed for all students. Substantial 
savings result in the storage of the DIAL machine. 

While such names cannot be used on the left hand 
side of an assignment statement , they can form text- 



expressions , e.g., 



SHOW obs| | pint 



There is a similar naming facility for slide 
constants , e.g., 



4.10 Repetition constructs 

DO-WHILE and REPEAT-UNTIL are available for con 
trolling the repetitive execution of a group of stat 
ments • They are motivated in [Dijkstra, 1970]. The 
constructs 



nesteddo = 233'J 



>> DO WHILE ? 



REPEAT 




UNTIL 



statement 
group 



can be diagrammed as follows: 



DO WHILE 



REPEAT UNTIL 



i r 



statement 
group 



( leading decision ) 



statemen* 
group 



t 



(trailing decision) 



Examples : 



(1) /* HARDWARE TEST PROGRAM */ 
/*Show all slides in carousel 3 
DCL s SLIDE 
s <- 300 
REPEAT 
S<- S + 1 
SHOW s 
UNTIL s = 3 80 



- */ 



(2) pint = 'Press INT to continue' 



REPEAT 

SHOW pint 
UNTIL PAT( ' ' ) 



8 4 

(3) I <- 1 

DO WHILE I <= 100 
SHOW I 
I «- I + 1 
ENDDO 

Format : 

DO WHILE J comparison-expr I 
| logic-expr j 

ENDDO [do-while-label] 
REPEAT 

comparison-expr i 
logic al-expr [ 

4.11 Cathode-ray tube screen formatting 

The CRT of the CC-30 can display 800 characters, 
arranged as 20 rows, each of 40 characters. Two aspects 
of CRT screen formatting concern the author, (1) the 
relative positioning of successive screen messages and 
(2) the relative positioning of characters within a 
message . 

( 1 ) Relative positioning of s ere en messages 

Successive text-expressions in a SHOW-s tatemer.t are 
separated by commas. When the statement is executed, 
each text -express ion is evaluated and treated as one 
screen message. Each screen message is displayed be- 
ginning at the next free screen row. For example, if 



UNTIL 



the text-variable GAM contained ! GAMMA 1 then the state- 
ment- 

SHOW J ALP 1 | | 'HA 1 , ! BETA 1 , GAM 
would result in 

ALPHA 

BETA 

GAMMA 

whereas the statement 

SHOW f ALP f | | ! HA f | | ! BETA f | | GAM 
would res ult in 

ALPHABETAGAMMA 
The above discussion applies to messages within 
the Q-area and A-area. The first SHOW-s tatement of a 
frame begins at the top of the Q-area. The QAR 
boundaries are floating and can be changed by assignment 
to the system variables Q VALUE, AVALUE, and RVALUE. For 
example , 

AVALUE <- 15 
RVALUE <- 17 . 

These three system variables have default values of 1, 11, 
and 13. An author must ensure that screen messages fit 
within the QAR division; overflows will be displayed in 
the next area, for example, a too large Q-area message 
will overwrite the A-area. 
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(2) Relative positioning of characters within a message 

The exact format of a screen message is important 
if the message is a table or list of items, whereas if it 
is entirely prose, its format is of less concern. 

For exact screen formatting, the SHOWAS-statement 
(to be read "Show as formatted") is used. It has the 
same syntactic format as SHOW, namely, 



When a display statement is encountered during 
execution, the DIAL machine, for each text-expression, 
evaluates the expression and then 

(1) if it is in a SHOWAS-statement the screen 
message is displayed as it was originally 
formatted , 

(2) if it is in a SHOW-statement the machine 
formats the message by removing instances of 
word-breaks over screen lines .^nd then displays 
the result. 



SHOWAS 




Examples : 



Statement executed : 

112 next: SHOW 'The slide screen abo 
ve is used for presenting the bulk of th 
e TEXTUAL MATERIAL. ' 

Result : 

The slide screen above is used for 
presenting the bulk of the TEXTUAL 
MATERIAL. 

Statement executed : 

250 S HO WAS 1 
DIAL has been designed for 
AUTHOR- CONTROLLED CAI T 

Result : 

DIAL has been designed for 
AUTHOR-CONTROLLED CAI 



Thus characters within text are formatted in two ways. 
By using SHOW > an author need not be concerned with word 
breaks as he is typing text. By using SHOWAS he can 
specify the exact layout of a display. 

The following illustrates the display of text constant 

Let the text be named by the statement 

150 studyslide= 'STUDY THE SLIDE ABOVE AN 
D PRESS INT TO CONTINUE.' 



Then typical uses are the following, 

Statement executed : 
750 SHOW studyslide 

Result : 



STUDY THE SLIDE ABOVE AND PRESS INT TO 
CONTINUE. 



Statement executed: 



8 50 SHOWAS studyslide 



Result 



■' STUDY THE SLIDE ABOVE AN 
D PRESS INT TO CONTINUE. 



Statement executed: 



9 50 SHOWAS studyslide, 'ALPHA' | | 'BETA' 



Result : 

STUDY THE SLIDE ABOVE AN 
D PRESS INT TO CONTINUE. 

ALPHABETA 



9 

ERIC 



89 



4.12 Light pen usage 

Instructional programs can be written so that a 
student indicates his response to a multiple-choice 
question by pointing with the light pen. 

Presenting the multiple-choice question 

The multiple-choice items are referred to as light 
pen targets and must obey the following rules. 

(1) Each item must begin with the character ' : J 

(2) Each item must occupy no more than one row; 

(3) There can be no more than eight targets. 
Figure 4.4 has four targets. An author will normally use 
a SHOWAS-statement to present his targets in a multiple- 
choice question. 

Recognizing the student f s response 

When a student points to a target and presses the 
pen's button, a l igh t pen hit is said to have occurred 
(the system recognizes only one hit at a time). An 
author specifies a hit and its branching action by using 
the system-matching-f unction PEN in a MATCH-s taternent or 
IF-statement . Examples are 

MATCH PEN(3) |PEN(5),L5 

and 

IF PEN(2) THEN SHOW DIAG 
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A complete example of light pen usage is given by the 
program segment in Example 4.6 and its execution in 
Figures 4 . 3 and 4.4. 



110 SHOW struck, ref, ! ADDRESS on line 5 
is followed by STREET , CITY, and STATE, 
which are all declared with a greater le 
vel number than ADDREST. You can see 
that STREET, CITY, and STATE are contain 
ed in ADDRESS. 1 
12 0 SHOWAS ' 

Since ADDRESS has data items in it, 
it is:- 

* a major structure 

* a minor structure 

* an elementary name 

* (none of these ) 1 
130 LI: MATCH PEN(2),* 

MATCH PEN(l) , MAJOR 
MATCH PEN(3) | PEN(4) , BAD 

140 BAD: 



180 MAJOR: 



Example 4.6 



1 

2 
3 
4 
■ 5 
6 
7 
8 
9 
10 
11 



DECLARE 
1 PERSONNEL, 
2 NAME 
2 PHONE' 
2 ADDRESS, 



1 YEAR_TO_DATE, 
2= GROSS F 
2 TAX • F 



3 STREET 
3 CITY 
3 STATE 



CHAR (25) 9 
CHARU5) , 
CHAR(2), 



FIXED DEC (8, 2) , 
FIXED DEC (7 , 2) ; 



CHAR (2 4) , 
CHAR(9) , 



Figure 4.3 -- The slide struc4 used in Example 4. 



Refer to the slide. 

ADDRESS on line 5 is followed by STREET, 
CITY, AND STATE, which are all declared 
with a greater level number than 
ADDRESS. You can see that STREET, CITY, 
and STATE are contained in ADDRESS. 

Since ADDRESS has data items in it, 
it is:- 



a major structure 
a minor structure 
an elementary name 
(none of these) 



Figure 4.4 - 



- An Execution of Example 4.6. 



4.13 The RESUME-statement 



The point at which a student terminates a particular 
session may not be the best point for him to begin his 
next session. It may be better pedagogically if he is 
restarted at a point just prior to the end of the last 
session. An author therefore places RESUME-s tatements 
at suitable points throughout the lesson. 

Format : 

RESUME 

Adtion : 

Causes the CAI System to copy the student f s com- 
plete status to the RESUMDUMP file. 

4.14 Subroutines 

4.14.1 Since subroutines in DIAL have the same definition 
and invocation conventions as subroutines in a general 
purpose programming language, they will not be described 
in detail. The specifications section of this chapter 
defines the CALL, PROC ^nd END statements needed. 

There ai*e two types of subroutine procedures - 
DIAL subroutines and PL/I subroutines. 
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(1) DIAL subroutines 



Example 4.7 is a subroutine, DELETE, to delete all 

. . 4 
occurrences of specified characters from ANSWER. A 

sample invocation is 

CALL DELETE ( 'AEIOU' ) 



DELETE: PROC(DELS) 

/"This subroutine deletes from ANSWER */ 
/"'all the occurrences of the characters in*/ 
/*DELS. . */ 

/"(Note the length restriction of 10 on */ 
/"DELC imposed by the dimension of */ 
/"vector C) */ 

DCL DELS TEXT /-Parameter-/ 

DCL L INTEGER /-Length of, i.e., number of -/ 

/-elements in, DELS - : / 

DCL C(10) TEXT /-Holds the elements after */ 

/-unpacking from t-LS -'/ 

L <- LENGTH ( DELS ) 

I <- 0 

I <- I + 1 

IF I > L THEN GOTO RETURN 

C(I) <- SUBSTRC DELS ,1,1) /-unpack next element-/ 

J <- INDEX (ANSWER, CCD) 
IF J=0 THEN GOTO OUTER 

ANSWER <- SUBST R (ANSWER, 1 ,J-1 ) | | SUBSTR( ANSWER, 

J+l) 

GOTO INNER 



OUTER: 



INNER: 



RETURN : 



END DELETE 



Example 4 . 7 



This subroutine also shows the use of vectors in 
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Example 4.8 is a subroutine , MULT I , to display 
multiple-choice items for light pen selection and to 
return the student's choice. A sample invocation is' 

CALL MULT I ('Point to the name ox 
the animal that barks : 1 , 
'dog 1 5 'cat' , ! rat f , a) 

( 2 ) PL/ 1 s ub r o u t in e s 

Subroutines written in PL/I can be called from a 
DIAL program. This provides a meapr of augmenting the 
power of DIAL. It is anticipated that experienced and 
resourceful authors will use this facility in their 
answer analysis. Experience will show which PL/I 
facilities are the most popular; these will then be 
considered for implementation in DIAL itself. 

Invocation of PL/I subroutines is exactly, the same 
as for DIAL, subroutines . The subroutine names, however, 
must be declared with the attribute PLISUB, e.g., 

DCL S ub PLISUB 

The subroutines themselves are defined outside of 
the CAI System. 

4.14.2 The name scope rule is as follows. The scope of 
a declaration is a lesson unless the declaration is within 
a procedure. Then Its scope is that procedure including 
all contained procedures except those containing another 



explicit declaration of the same identifier. 



MULT I : PROC (PREAMB 5 ITEM1 , ITEM 2 5 ITEM3 5 PENR) 

/*A subroutine to present three multiple- */ 
/"choice items for light pen selection, A 
/"preamble in PREAMB introduces the items. */ 
/"The student response is returned in PENR. */ 

DCL PENR INTEGER 

/"""Present multiple -cho i ce : - **/ 
SHOW PREAMB 

ITEM1 <- r - MliTEMl /-Prefix * */ 
ITEM2 <- T * 1 I I ITEM2 
ITEM3 <- f ft Mi ITEM3 
SHOWAS ITEM1 , ITEM2 , ITEM3 

/- : ""Read student response: - **/ 

IF PEN(l) THEN PENR <- 1 

IF PEN(2) THEN PENR <- 2 

IF PEN(3) THEN PENR <- 3 
END MULT I 



Example 4.8 



H . 15 Input -output synchronization 



Output from a DIAL program, effected by the SHOW 
or SHOWAS statements, consists of a CRT display or the 
projection of a slide. Input to the program, effected 
by the MATCH statement, is a typed or penned response. 
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Output 

Although a SHOW or ">H0WAS statement may contain 
several separate text-expressions and a slide, each 
separated by a comma in the operand list , these separate 

5 

items are displayed without any time delay between them. 
There is , however , a time delay equal to the setting of 
the PAUSE register between two successive SH0W 1 s without 
an intervening MATCH. 

Input 

There is no explicit read statement in DIAL; reading 
is implicitly requested by MATCH -statements . The first 
MATCH-statement encountered after a SHOW causes the DIAL 
machine to issue a read - the blue Proceed light (Keyboard 
Enabled light) comes on and the read is completed when the 
student sends his response by depressing INT. If the next 
statement to be executed is also a MATCH statement, it 
will not issue a read but will perform the answer matching 
using the contents of the ANSWER register filled by the 
preceeding MATCH-statement. These rules apply not only to 
MATCH but also to PEN and PAT. 



If there is more than one slide, only the one 
appearing last will remain projected. 
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To further clarify this synchronization consider the 
DIAL machine's internal mechanism to effect it. An 
internal switch named READISSUED is tested by each state- 
ment that accesses the student's response. If READISSUED 
is of f ^ then a read is issued and the switch turned on, if 
it is on then no read is issued. It is also turned off 
by a SHOW-statement and an UNREC-stavement . 

As an example, trace an execution of the following 
DIAL program segment of nine statements 

1 SHOW 

2 show 

3 SHOW 

4 match 

5 Match , lb 

6 Match 

7 UNREC *,*,L3 

8 L5: SHOW 

9 show 

The trace could be 

Statement Number Action 

1 show 

2 pause 
show 

3 pause 
show 

4 no pause 
read 

unsuccessful match 

5 no read 
unsuccessful match 

6 no read 
unsuccessful match 

7 show UNREC-message 

4 read 
unsuccessful match 

5 .no read 

successful match 



9 

ERIC 



9 8 



8 no pause 
show 

9 pause 
show 



Note that the sequence which controls the synchroni- 
zation is the order of execution ,, not the (sequential) 
statement numbering. A trace of the following interaction 
( involving a subroutine call ) further exemplifies this 
point . 

1 SHOW 

2 SHOW 

3 CALL PINT 

4 SHOW 

5 SHOW 



10 0 PINT: PROC 

/• : Thi.s procedure returns control to the * I 

/• f calling point when a plain interrupt has */ 

/• t; been received. The PAUSE register */ 

/*is zeroed for the duration of PINT so */ 

/*that the proceed request is displayed */ 

/ "immediately */ 



101 DCL SAVEL INTEGER 

102 SAVEL <- PAUSE 
10 3 PAUSE <- 0 

104 LI: SHOW 'Press INT to continue' 

105 M r r , L2 

106 GOTO LI /-not plain interrupt */ 
10 7 L2: PAUSE <- SM'EL 

10 8 END PINT 



Trace : 

Statement Number Action 



1 


show 


2 


p au s e 




show 


3 




100 




101 




102 




103 




104 


pause (of zero seconds) 




show 


105 


read 




unsuccessful match 


106 




104 


no pause 




show 


105 


read 




successful match 


10 7 
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no pause 




show 


5 


pause 




show 



4.16 DIAL specifications 

Since this section can be used for reference purposes > 
the following listing of section headings may be useful. 

4.16.1 Message preprocessing 

4.16.2 Statements 

( 1) Declarations 

(2) Input/output to the student 

(3) Branching 

( 4 ) Assignment 
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(5) FRAME-statement 

(6) DO-group head 

(7) PKOC-statement 

(8) END-statement 

(9) CALL-statement 

( 10) ENDLESSON-statement 

(11) RESUME-statement 

( 12 ) Naming-st atement 

( 13 ) Repetition statements 

4.16.3 Text franipulacion 

4.16.4 Expressions 

4.16.5 System matching functions 

4.16.6 Light pen usage 

4.16.7 Default actions 

4.16.8 Abbreviations 

4.16.9 Restrictions 

The metalanguage used to define the syntax of DIAL is 
a subset of the syntax notation used in IBM PL/I publica- 
tions [IBM 1970b : Section A] and is given in Figure 4.1. 

The CAI System has been designed so that an author 
can take the view that he is programming a "DIAL machine. TT 
This machine, which is diagrammed in Figure 4.5, has the 
following characteristics : 
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(1) it directly executes DIAL statements without the 
need for translation; 

(2) it has a one-level store, which can hold 
arbitrarily large programs. 

This view is possible because the CAI System has been 
implemented in accordance with the "onion structure" given 
in Figure 4.6. 

4.16.1 Message Preproces sing 

A student's typed response is always preprccessed 
before author-specified answer classification, or matching, 
begins . 

Automatic preprocessing 

The preprocessor always does the following: 

(1) strips preceding and following blanks surrounding 
an answer 

(2) squeezes excess blanks between non-blank 
characters in an answer. 

Example : 

Let ft represent the blank character. If the 
answer typed by a student is 

J6XiS=J6iSAiSiS+16BiS ; iSiS 
then the ANSWER register contents after automatic pre- 
processing will be 

XiS=tSAJ6+J6B16 ; 
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Switchable preprocessing 

Wher the CASE switch is on, all lower case letters in 
a typed response are converted to upper case as ANSWER is 
being filled. CASE is in the on state by default. 

When the SQZ switch is on, all blanks are squeezed 
(removed) as ANSWER is being filled. SQZ is in the on 
state by default. 

The SQZ and CASE switches are actually registers 
holding INTEGER data in the DIAL machine. The on/off 
states are 

on register non-zero 

off register zero 

Since both SQZ and CASE are system variables , their 
settings can be changed by assignment statements, e.g., 

CASE <- 1 
SQZ <- 0 

Although these registers are set by assigning in- 
tegers to them, when they are read they return a truth 
value. Thus 

IF CASE THEN CASE <- 0 

and 

IF ~i SQZ THEN SHOW MSG 
are valid, but the following is not: 

IF CASE = 10 THEN CASE <- 0 



4.16.2 Statements 

A DIAL lesson, or program, is constructed from basic 
program elements called statements . Statements make up 
larger program elements : DO-groups , frames , procedure- 
definitions, REPEAT-UNTIL blocks, and DO-WHILE blocks. 
A DO-group is a sequence of statements headed by a D0- 
statement and terminated by a corresponding END-s tat erne nt . 
A frame is delimited by a FRAME-s tatement and an END- 
statement . A procedure-definition is delimited by a 
PROC-statement and an END-s tatement . 

Execution passes sequentially into and out of a frame, 
whereas a procedure must be invoked by a CALL-s tatement . 

Comments are enclosed between the markers /* and */ 
and may be placed anywhere in a DIAL program that a blank 
is permitted . Any characters may be used in a comment 
except the pair */ , which ends the comment . Comments 
are completely ignored by the DIAL machine . 

Definitions of each statement follow. 

(1) Declarations - the DCL-statement and attributes 



Syntax: 




identifier attribute-specification 
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Action : 

The statement is used to declare explicitly the 
attributes of identifiers. The attributes in 
DIAL are: 

TEXT 

SLIDE 

INTEGER 

PLISUB 

GLOBAL 

LABEL 



The attribute specification contains the attribute 
name and, when allowed, a vector dimension. 
A DCL-statement may appear anywhere in a lesson 
as long as it appears before the first use of the 
identifier it names . 

(a) Vector identifiers 

An identifier may name a vector (a one- 
dimensional array) of variables of the same 
attribute. The dimension of the vector 
precedes the at tribute -name and is enclosed 
in parentheses. For example, 

DCL SCORES(IO) INTEGER 

(b) Label vectors 

These vectors allow a "computed-GO-TO" facility 
in DIAL and can be used only in this way. 
There are no label variables as in PL/I. 

(c) Constants and' slide constants 

When an identifier appears in a naming-s tatement 
it is given the TC or SC attribute; TC and SC 
cannot appear in a DCL-statement. 

(d) GLOBAL 

Identifiers with this attribute have the 
implied attribute INTEGER and have name scope 
across all lessons in a course. 
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Note that the )INCLUDE facility (Chapter 5) 
provides a means of giving text constant :■• 
global scope . 



(e) PLISUB 

If arguments are to be sent to the PL/I sub- 
routine then the attributes of their correspond- 
ing parameters must be given . If a parameter 
is a vector then this is indicated by appending 
(#) to the attribute. For example, 

DCL P PLISUB (TEXT , INTEGER ( # ) ,TEXT) 

would define a subroutine with three parameters, 
A sample invocation is 

CALL P (ANSWER, SCORES, REPLY) 

(f) Summary 



{DCL 1 
NEW I 



DCL 
NEW 



identifier C (dimension) 3 



TEXT 
SLIDE 
INTEGER 
GLOBAL 



identifier (dimension) LABEL 



|DCl{ identifier PLISUB 
iNEWf 

j [ (parameter-attribute -list) ] 
(2) Input/output to the student 
a. SHOW-statement 
Syntax : 



SHOW 



ftext-expr 
si ide-expr 



Itext-expr 
slide-expr ! 
arith-exprj 
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Actio n : 

Each expression is evaluated and then sent as an 
output to the terminal. 

(a) text expressions 

each character string is treated as a 
separate screen message and is displayed 
at the beginning of the next free CRT row , 
Characters appear with no words broken 
over rows* 

(b) slide expressions 

the slide is shown , and remains projected 
until the next slide action. 

( c ) arithmetic express ions 

the result of the evaluation is converted 
to character form and displayed on the 
next free row . 

Examples : 

SHOW 1 Central Processing Unit 1 
SHOW ANSIS| | ! UNIT f , 'Refer to the 
slide above 1 ? DIAG2 

SHOWAS-statement 

(to be read as "Show as formatted") 
Syntax : 



SHOWAS 



Action 



text-expr 
slide-expr 
arith-expr 



text-expr 
3 { slide-expr 
ar_Lth.-expr I 



As for SHOW-atatement except that no word-break 
removal is performed on text . Thus characters 
are formatted exactly as they appeared when 
originally entered. 
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CRT screen formatting 

Q AR screen division 

The CRT screen is divided conceptually into 
three areas: Question, Answer, and Response: 



Q 



A 



R 



The Q area is filled by one or more SHOW f s 
presenting a question. When a MATCH is 
encountered , the cursor is placed at the 
beginning of the A-area for the student 
to enter his answer. The author's feedback 
re s pons e appears in the R-area and the 
cursor is then placed back in the A-area so 
inviting the student's next attempt. 

The Q'AR boundaries are floating and can be 
changed by assignment to the system variables 
Q VALUE 3 A VALUE 5 and RVALUE. Their default 
settings are 1 , 11 , and 1 3 . 

Relative positioning of successive screen messages 

Each successive text -express ion results in a 
SHOW-statement or SHOWAS-s tatement is displayed 
beginning at the next free row in the Q-area or 
R-area. 



9 

ERLC 
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Relative positioning of characters within a 
message 

This positioning is done by the system accord- 
ing to whether SHOW or SHOWAS is used. 

d . Duration of s lide showing 

A slide shown will remain projected until 
one of the following occurs : 

(1) the system slide constant RMV is shown 

( 2 ) a new f rams begins execution 

( 3 ) another slide is shown 

(4) )0FF is received. 

Note that RMV is an opaque slide occupying 
position 0 of each carouse 1 . Thus only 
positions 1 through 80 are for author use. 

e. Reading a student f s response 

The keyboard will be enabled 5 so inviting 
a student 1 s typed or penned response 5 whenever 
the first MATCH-statement after the controlling 
SHOW-statement ? or SHOWAS-s tatement , is executed. 
The response is then read and processed by 
MATCH-statement(s) . 

(3) Branching 

a. MATCH-statement 



Action : 

If at least one of the operands matches the 
ANSWER register then the program branches to label 
(or takes the default branch if *). Otherwise 5 
the next statement is executed. 



Syntax : 




• • • 5 




1 ]. I 



Examples 











| label 




" ) 


label] 














_' ) 


L 9 I. 



MATCH 1 Identifier 1 | JOE | ' Variable 1 , L5 
MATCH PENC3) |PEN(5) , L7 
MATCH PEN(I) , RESP(I) 
MATCH PAT( ' $AB<: * ) ,* 

UNREC-statement 

Syntax : 

UNREC 
Act ion : 

The i unrecognized response to the controlling 
SHOW-s tatement will cause a branch to the i^h label 
in the UNREC label list. 

Example : 

UNREC *, *, L3 

Unconditional branch 

Syntax : 



I GOTO I 
|G0 TOj 



label 1 



Examples : 



GOTO * 

GOTO L4 

GOTO ARITH ( 4 ) 



IF-THEN -ELSE 
Syntax : 

comparison-exprl 



IF 



logical-expr 



THEN 



statement 
DO -group 



9 

ERIC 



ELSE 



statement | 
DO-group j 
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Action : 



The expression in the IF-clause is evaluated 
to give a truth value as result. 

C ase 1 : ELSE-clause not present : 

If the truth value is 1, the THEN-clause is 
executed and control pass es to the statement 
following the IF-statement . 

If the truth value is 0, the THEN-clause is 
not executed. 



Example : 
IF QCOUNT > 3 THEN X <- X + 1 



Case 2: ELSE-clause present : 

If the truth value is 1, the THEN-clause is 
executed and control skips the ELSE-clause and 
passes to the next statement . 

If the truth value is 0, the THEN-clause is 
skipped and the ELSE-clause is executed . 



Example : 

IF NQN(2) > 3 THEN X <- X + 1 
ELSE X <- X - 1 



Assignment 
Syntax: 

{ text-expr I 
variable <- < slide-expr } 
I arith-expr J 

Action : 

The expression on the right hand side is evaluated 
and the result is assigned to the variable on the left 
hand side. No data conversion is done; the attributes 
of the variable on the right hand side must agree with 
the attribute of the right hand side result. Identi- 
fiers with the TC or SC attributes may not. appear on 
the left hand side. Note that the system variables 
CASE, SQZ and PAUSE are set by assignment. 
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(5) FRAME-statement 
Syntax : 

frame -name : FRAME 
where frame-name is an identifier. 
Action : 

Serves to define the beginning of a set of state- 
ments which constitute a frame. Use of the frame 
facility is optional. It is used to take advantage 
of default branching and default screen formatting. 

(6) DO-group head 
Syntax : 

[DO-group-label:] DO 
where DO-group-label is an identifier . 
Action : 

Serves to define the beginning of a DO-group. 

( 7 ) Procedure-statement 
Syntax : 

procedure-name : PROC [ ( parameter [ 5 parameter] . . . ) 3 
where procedure-name and parameter are identifiers. 
Action: 

Serves to begin a DIAL procedure definition and 
to define the procedure's parameter list. 

(8) END-statement 



Syntax : 

END 



procedure -name 
frame -name 
DO-group-label 
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Action : 

a • procedure-name 

Serves both to end the definition of a procedure, 
and upon execution 5 to return program control to 
the calling point. 

b . frame-name 

Defines the end of a frame 

c. DO-group 

Defines the end of a DO-group. 
(9) CALL-stateTient 
Syntax : 

CALL procedure -name [ ( argument [ ,argument ] . . . ) ] 
Action : 

The procedure named in the statement is invoked 
with the arguments (if any ) in the argument list . 
Execution resumes at the statement following the 
CALL-statement . 

(10) ENDLESSON-statement 

Syntax : 

ENDLESSON [lesson-name] 

Action : 

The following system message is displayed: 
END QF LESSON 

DO YOU WISH TO GO ON TO THE NEXT LESSON? 
TYPE Y£S OR )0FF 
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(11) RESUME- statement 
Syntax : 

RESUME 

Action : 

Defines a resume point in a lesson . Chapter 5 , 
Section 6, defines the RESUME process. 

(12 ) Naming-s tatement 
S yntax : 

identifier 



text-const 
slide-const j 



Action : 



Names a read-only constant and gives the TC or 
SC attribute to the identifier. Note that such 
identifiers cannot appear on the left hand side of 
an assignment statement . 

Examples : 

pint = 1 Press INT to continue 1 
MVT = 2 705 

(13) Repetition statements 

Syntax : 

( comparison- exp I 
\ 
logical exp | 



group of statements 
ENDDO [do-while-label] 



Action : 



The group of statements so bracketed is repeat ffHy 
executed while the expression in the DO-WHILE clause 
remains true. The decision is made be fore each 
q repetition. 

ERIC 
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Syntax : 

RF?EAT 



group of statements 



comparison-expr 
UNTIL I > 
I logical-expr J 

Action : 

The group of statements so bracketed is repeatedly 
executed until the expression in the UNTIL clause 
becomes true. The decision is made after each 
repetition; thus the group will be executed at least 
once , 



4.16.3 Text manipulation 

The three operators 

SUBSTR, 
INDEX, and 
LENGTH, 

together with concatenation, form a workable set of primi- 
tives for text manipulation. The definitions of SUBSTR, 
INDEX and LENGTH in DIAL are exactly the definitions of the 
built-in functions of the same names in PL/I-F [IBM 1970b: 
.Section G] and are summarized as 
SUBSTR (text-expr, j [,k]) 

INDEX (text-expr , conf iguration-text-expr) 
LENGTH (text-expr) 

Examples of string expressions using these operators 

are : 

A || B || SUBSTR (ANSWER, 1, 3) 
SUBSTR (EXAMPL, 1NDEX(C , 1 16 1 ) + 1) 
LENGTH (ANSWER) 

SUBSTR (INFORM, 4) | (ANSWER) | 'what you meant 

to type?' 
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4.16.4 Expres sions. 

An expression is a representation of a value. A 
single constant or a variable is an expression. Combina- 
tions of constants and/or variables, along with operators 
and/or parentheses, are expressions. An expression that 
contains operators is an operational expression . The 
constants and variables of an operational expression are 
called operands . 

The rules for the five clas ses of expressions in 
DIAL are as follows : 



Clas s 


Operators 


Valid 
Operands 


Result 


Example 


STRING 


SUBSTR 
II 


TEXT variables 
TC 

text constants 


TEXT 


A| 1 'Dog' 
SUBSTR(ANS,4)| |X 


SLIDE 


+ - 


SLIDE variables 
SC 

slide constants 
INTEGER variables 
INTEGER constants 


SLIDE 


mvthm + 1 


ARITH- 
METIC 


+ - * 


INTEGER variables 
INTEGER constants 


INTEGER 


a + b 

A+B*C*(X-Y) 


LOGICAL 


8 1 - 


expressions hav- 
ing truth values 


t :;^uth 
value 


(AA=1)6(BB=1 ) 
PAT( 5A7^ ' ) 



COMPARI- 
SON 


> > = 

< < r 
- —\- 


any expression 
other than 
logical 


truth 
value 


I > 4 

ANSWER - A| 1 B 
LENGTH (ANC )> = 4 
IDENT > 'DOG' 



ERLC 
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Operands combined by an operator to form an expression 
must have the same attribute, 

4,16,5 System matching functions 

The smf's are PEN and PAT; both of them 

(1) operate on the student's response (the contents of the 
registers ANSWER or PEN(l) 5 . , . 5 PEN( 8) , and 

( 2 ) return a truth value . 

a, PEN 

Syntax : 

PEN ( arith-expr ) 

Action : 

The results of the arithmetic-expression must 
be one of the integers 1 through 8. PEN (i) 
returns the truth value 1 if the light pen hit 
occurs on the i^* 1 multiple-cho ice entry. 



Examples 



PEN(U) 
PEN(I) 



b, PAT 

Syntax : 

Action : 



PAT( text-expr) 



The text-expresaion defines a pattern and 
PAT returns the truth value of 1 if the pattern 
matches ANSWER, 

The pattern is made up of a series of pattern 
element's separated by a cent symbol, the "don't 
care" symbol , where noise characters may appear . 
A match occurs if each of the pattern elements 
(in the order they appear in the pattern) occurs 
in ANSWER. The symbol. <t cannot be in a pattern 
element . 



1 J 9 

Examples : 

(1) To test if ANSWER contains the key-letters 
A, B, and C: 

PATC ' CACBCCC' ) 
Note there are three pattern elements . 

(2) To test for a substring of ANSWER 

EX <- ' CAN DC ' 
MATCH PAT (EX) ,L4 

(3) To specify an answer of the form 
"NEXT: CALL P (ALPHA, BETA) ; " : 

SHOW 'Give an example of a statement 
which invokes the subroutine P 
having two parameters ' 

MATCH PAT('CCALL PC ( C , C ) C ; C 1 ) , L5 

The pattern elements in this example are: 

CALL P 
( 

5 

) 



PAT( 1 1 ) matches only the null string. 
PAT( ! t*) matches all strings. PAT( ! AtB') will 
match 1 AB * . 



4.16.6 Light pen usage 

Multiple-choice items as targets must obey the 
following rules 

(1) each item must begin with the character * 

(2) each item must occupy no more than one row 

(3) there can be no more than eight targets. 
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Light pen hits are specified by the PEN smf . The system 
recognizes only one hit at a time. 

4.16.7 Default actions 



Item 
Attribute 
CASE 
SQZ 
PAUSE 

Branching with 
MATCH 

UNREC 



Default 



GOTO 
QVALUE 
AVALUE 
RVALUE 



TEXT 

on 

on 

2 seconds 



"Right" is displayed in green, then 
branch to next frame. 

The following message is displayed in 
yellow . 

Your answer was not recognized. It may 
be wrong ? or it may be right in content 
but wrong in form, spelling or punctua- 
tion. Examine your answer and try again. 

Branch to next frame . 



1 

11 
13 
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4.16.8 Abbreviations 

These abbreviations are accepted : 



Word Abbreviation 

ANSWER ANS 
MATCH M 
SHOW S 
SHOWAS SAS 
UNREC U 



4-16.9 Restrictions 

(1) Character s.et 

The CC-30 character set, for the purposes of 
DIAL programming, is divided into ordinary 
characters (those which have significance in the 
language) and string characters (those which may 
only occur in character string constants). 
Ordinary characters : 

A j B j C j • « » j Z j 3. jb j c j • • • j z 

0 3 1 , • • . 5 9 

# 6 1 ()*+,-: i 
<=>-,){ 

String characters: 

!"$%./?@\MLJ 
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(2) Length of Character strings and DIAL statements 
The CRT screen imposes the maximum length - , since 

there are 800 characters displayable on the CRT, and 
the CAI System reserves the use of rows 18, 19, and 
2 0 in author mode, the maximum character string 
length and statement length is 680. 

(3) Length of identifiers 

All identifiers, CAI System-wide, may be up to 
ten characters long. 

(4) Reserved words 

These words may not br used as identifiers: 



ANS 

ANSWER 

CALL 

CASE 

DCL 

DO 

ELSE 

END 

ENDDO 

ENDLESSON 

FRAME 

GLOBAL 

GO 

GOTO 
IF 



MATCH 
NEW 



INDEX 

INTEGER 

LABEL 

LENGTH 

M 



REPEAT 
RESUME 



PAT 



PAUSE 
PEN 



PLISUB 
PROC 



RMV 
S 

SAS 

SHOW 

SHOWAS 

SLIDE 

SQZ 

SUBSTR 

TEXT 

THEN 

TO 

U 

UNREC 
UNTIL 
WHILE 



ERIC 



ERIC 



(5) Other 
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Item 



Integer 

PAUSE 

Slide 
carousel range 
slide range 

Number of light 
pen targets \ 1 to 8 

PAT pattern elements 1 to IB 

PAT pattern element 

length 1 to 80 



Range 
-32768 to 32767 

0 to 12 0 seconds 

1 to 100 
1 to 80 



CHAPTER 5 
THE OPERATIONAL ENVIRONMENT 



5 . 1 The host computer system 

Instead of using a computer dedicated to CAI , as most 
workers have done, this project planned to use the IBM 
System/360 at the Triangle Universities Computation Center 
(TUCC), of which UNC is a one-third owner. Although a 
dedicated machine may be appropriate for public-school use, 
the use of a general campus facility, with both its system 
and staff resources, is especially economical for colleges. 
The major difficulties with this approach occur during 
system development and are common to most projects which 
involve embedding a sophisticated sub-system, using 
essential but often privileged services, into a host 
system already serving a large community of users. The 
approach was explored during Phase I of the UNC project 
and found to be sufficiently feasible in terms of system 
debugging inconvenience and service rece ived by the 
working system, to adopt the same approach in the Phase II 
system. Although debugging in a non-dedicated environ- 
ment is considerably more difficult, the benefits in our 
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case, in addition to the economic ones, were considered 
to be worth the price paid. These benefits result from 
the extended scope of a comprehensive operating system 
(CS/360 with the MVT - Multiprogramming with a Variable 
number of Tasks - option) and include: 

(1) the availability of PL/I a- the language for 
programming the CAI System 

(2) the availability of other lc iguage processors 

a. the Conversational Progra-iming System (CPS), 
possibly for extending the answer processing 
capability of DIAL 

b. the PL/I (F) level compiler for portions 
of the answer analysis of constructed 
responses as suggested in Chapter 9. 

(3) comprehensive file handling capability used for: 

a. instructional program storage 

b. loggi-g (data gathering) of student 
responses 

c. the File Management System of the CAI System, 

(4) a well established teleprocessing environment 
The primary data communications programs for- the 
CAI System (those supporting the multiplexed 
CC-30 ! s) are in the CHAT System. However, 
secondary requirements, e.g., administrative 
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programs, data analysis programs and systems 
debugging programs, were met by the existing 
remote job entry facilities of TUCC. 
The TUCC system is described in [Brooks., et al . , 1968 ; 
Freeman 5 19 68 Freeman and Pearson, 1968] where both 
technical and organizational aspects are discussed . The 
hardware configuration during the early part of the CAI 
System development was: 
S/360 Model 75 CPU 

Main Storage 1024K bytes 

Large Capacity Storage 2048K bytes 

Disk Units 3 x 2314 

Drum Units 2 x 2301 

Magnetic Tape Units 1 x 2401-11, 4 x 2402-11 
Line Printer - 140 3 
Card Reader-Punch 2540 
Communications Equipment 

2701 Data adapter for high speed lines to 

S/360 ! s at Duke, NCSU and UNC 
2703 Transmission control with 48 ports for 
low speed terminals 
During the summer of 1971, TUCC replaced its Model 75 
by a System/370 Model 165 with 2048K bytes of main storage. 
Replacing UNC's Model 50 as its on-campus terminal to TUCC 
is the Model 75 formerly at TUCC. The CHAT System, under 
which the CAI System runs, was developed and operated on 



the Model 75 while it was at TUCC. It operates entirely 
from the low-cost 8 microsecond storage (LCS). The new 
Model 165 at TUCC does not have such storage; its two 
million bytes of fast storage are less than the former TUCC 
configuration. Therefore the CHAT System was moved to 
UNC with the Model 75 5 and it continues to operate from 
slow core. 

The host computer system for production use of the 
CAI System is therefore a System/ 360 Model 75 with the 
following configuration. 
S/360 Model 75 CPU 

Main Storage 256K bytes 

Large Capacity Storage 1024K bytes 

Disk Unit 2314 

Magnetic Tape Units 2 x 2415 

Line Printers 2 x 140 3 

Card Reader-Punch 2 54 0 

Card Reader-Punch 2540 I housed in IRSS 

y building 
Line Printer 1403 j nearby 

Plotter 

Graphics Dis pla f System 

Vector General and PDP-11/45 

Communications Equipment 

2 701 Data adapter for high speed line to TUCC 

1270 (Memorex) Data adapter for low speed and 

medium speed lines 
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CC-7012 (CCD Channel adapter 

5 . 2 T he Chapel Hill Alphanumeric Terminal (CHAT) System 

The CHAT System was designed and implemented by 
Gary D. Schultz [1973] of the UNC CAI Project. It is a 
single-region"*" resident time-sharing system wherein 
various programs share the execution time by CHAT ! s use 
of the OS/MVT multitasking facilities. An application 
program runs as a subtask with respect to one of the 
executive tasks of CHAT. This monitor program also 
provides the CC-30 input/ output programming support to 
application programs . 

While CHAT was operating at TUCC, a medium speed 
communication line (2400 bits per second) connected the 
CAI Center to TUCC. The proximity of the CAI Center to 
the UNC Computation Center installation has made it 
possible to dispense with the communications line and use 
a direct hardwire connection instead. The CHAT System 
hardware configuration at UNC is shown in Figure 5.1. 
The line transmis s ion speed with this direct connection 
causes the CRT screen to be filled in one-tenth of a 



The main memory subdivision that is allocated to a 
job step in OS/360 is known as a region under the MVT 
option and a partition under MFT. 



1.2 9 




a) 

•H 
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second. Using the former 2400 bit line, we experienced 
a 2 1/3 second screen-fill time, which wc found to be 
quite adequate. 

The UNC CAI System is a complete subsystem running 
as an application program under CHAT, Other subsystems 
include Brown University ! s Hypertext editor , a numerical 
analysis laboratory simulator and an interactive 
assembler . 

Access to a subsystem of CHAT is provided by the 
CHAT Monitor Table of Contents (MTOC) display shown in 
Figure 5.2. The default selection is CAI, i.e., de- 
pressing INT in response to MT0C ! s invitation is equiva- 
lent to either pointing to CAI or typing CAI and 
depressing INT. 

5 . 3 The student/author work station 

5.3.1 The work station, pictured in the frontispiece, is 
designed around a Computer Communications Incorporated 
CC-30 Communications Station. The work station is 
normally used by just one person (a student or author) 
but has been designed also to allow two students t ;j be 
seated so that we can experiment with learning in pairs, 
with perhaps one student using the keyboard and the other 
the light pen. 




* L1.CHTPEN *M of d*iir«d 

* TYPE oro^^w h*r% : / > 



gure 5.2 — The CHAT Monitor Table of Contents 

(MTOC) display. 
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Output to the user is displayed either on the CRT or 
on the slide s creen above the CRT . A further output 
facility, audio tape, is being studied for later 
inclusion . 

Input from the screen is either a message typed from 
the keyboard and displayed on the CRT, or a light pen 
position on the CRT. 

A desk work area is part of the work station; authors 
can use it for course-plan notes, instructional program 
listings, etc.; students for note-taking and performing 
exercises which require pen and paper. 

A proctor call switch is mounted on the left side jf 
the display housing. When switched, a buzzer sounds in 
the proctor office and panel lights show which station is 
calling . 

5.3.2 The CCI Co mmunications Station 

The nucleus of the station is the CC-301 TV Display 
Controller. This has three major sections: ,a magnetic 
core buffer memory , a character/graph generator , and an 
input-output section. The buffer has two functions: it is 
both the data source for refreshing the CRT, at the rate 
of sixty times per second, and the storage facility for 
the station. 



J. 1 1 

The CC-300 TV Display is a standard television set 
or television monitor. In the alphanumeric mode the 
characters stored in the buffer memory in ASCII format are 
displayed on the CRT in a format of 20 lines of 40 
characters each. When operating in graph mode, data are 
displayed by means of a 108 x 85 matrix of dots. 

The CC-30U Light Pen, similar in shape, size and 
weight to an ordinary fountain pen, employs a photo- 
transistor detector • When it is directed towards the 
display, a marker appears on the CRT indicating the 
character position at which the light pen is positioned. 
This marker is a brightening of the character background. 
The coordinates of the character are stored in the CC-301 
when the interrupt button on the pen is depressed. 

A tandard Mouel 35G Kuudk Rcuiuom Access Carousel 
slide projector is connected as an output unit to the 
CC-301 by a specially designed interface. The four 
commands for the projector are: lamp on, lamp off, 
show slide nn and show the next slide. 

Further details on the station are given in the 
manufacturer ! s manual. - [CCI, 1968], 

5.3.3 Gaining access to the CAI System 



As soon as the user is seated at the work station he 
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depresses the INT key, which results in the CHAT Monitor 

2 

Table of Contents display of Figure 5.2. Depressing 
INT once more initiates the CAI System which then 
invites the user to sign-on, by displaying the message 

SIGN ON BY ENTERING YOUR ID 

)SIGN ON 

Whether he is an author or student is determined by 
his identification number* An author is put under the 
control of the program routine AUTHOR and invited to enter 
his first command. A student identification number causes 
the appropriaxe instructional program to be loaded and 
execution of it to begin, after a restart procedure if 
necessary . 

5 . 4 System overview 

This section is intended to provide a background to 
the discussion, in subsequent sections, of author and 
student use of the system. 

The overall flowchart of Figure 5.3 shows the two 
main parta of the CAI System, student and author modes. 



This is the only direct contact (c.f. Figure 4.6) 
that a CAI System author/student user has with CHAT 
under normal operating conditions. 



START 
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)off 
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pointing recovery 
information 
until 

)off 
or collapse 



END 



Figure 5.3 An overall flowchart of the CAT 

System. 



Student mode 



Presentation of course material to a student occurs 
in this mode. The instructional programs prepared by 
authors are executed in a paging environment implemented 
in the CAI System. The run-time storage environment 
for each student's execution of a program is carried from 
one session to the next. Each action of a student is 
logged for later off-line analysis , and status information 
is continually checkpointed to minimize the effects of 
system breakdown on students' progress and attitudes. 

A uthor mode 

Preparation of course material occurs in this mode. 
A command language interpreter controls the compiler 
ior DIAL and author testing of program segments. The 
system tries to anticipate, at every step during inter- 
active programming, the author ! s next type of input. 

Protection 

There is absolute protection of a lesson in use by 
students from author tampering. Identification number 
protection is provided between users (both authors and 
students). Protection against UNC Computation Center 
system failure, CAI equipment failure and CAI software 



failure is attempted. Additionally, the operator in 
student mode is protected against making any change in 
course material or any explicit change in other files. 

Course structure 

A set of lessons constitutes a course; the only 
communication between lessons is by means of identifiers 
with the GLOBAL attribute. Such a course structure was 
designed to meet the following requirements 

(1) flexibility in course preparation ; 

(2) . the setting of a practical (from an implementa- 

tion view) maximum program size; 

( 3 ) protection of sections of course material in 
student use from author tampering. 

File management system 

With the exception of the student record and author 
record files, which are held on two OS/ 360 ISAM (Indexed 
Sequential Access Method) data sets, all logical files fo 
the CAI System '(files for log, instructions, source code, 
recovery j directories, etc.) are held on one physical 
OS/ 360 BDAM (Basic Direct Access Method) dataset named 
CAIFILES. The File Management System, the part of the 
system which handles the management of CAIFILES, is not 
described in the thesis since it is not seen by the user, 
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but is covered elsewhere in the system documentation 
[Mudge , "19 7 2'] . Briefly, its functions are to handle 

(1) disk storage management; 

(2) the various logical files; 

( 3 ) the coordinated use' of external serial lv 
reusable resources ; 

(4) directories of courses, lessons, source code, 
etc. 

5 . 5 Instructional programming in DIAL - author use of the 
system 

Since Chapter 4 gives the DIAL specification, we are 
here concerned only with the command language, i.e. , we 
treat the mechanisms for interactively programming in DIAL. 

Each command is preceded by the character ) , e.g., 
)list, chosen because no syntactically valid construct 
in the language can begin with closing parenthesis. 
The author converses with AUTHOR by means of the command 
language and the statement-n umbering mechanism. 

Before a DIAL statement can be entered, the lesson to 
which it belongs must be defined. If a new lesson is 
being created, the )lesson command is entered, in the 
format 

) lesson lesson-name 



l :h 



and causes the appropriate directory entries to be made 
and disk storage space allocated. If a DIAL statement 
being entered is to be a change or an addition to an 
existing lesson, then that lesson is defined by the )load 
command . 

A statement number must appear to the left of each 

DIAL statement. It provides the author and the system 

with a way of referring to the statement which follows it. 

Consequently, every statement number must be unique; if two 

statements are entered with the same number, only the one 

typed last will be retained. Numbers must lie between 1 
3 

and 9999. The author can ask the system to generate 
statement numbers by preceding any line with )m,n where 
m is the base number and n is the desired increment. The 
system signifies its acceptance of a valid numbering 
request by overwriting the request with the first 
statement number.' For example, 

)200,10 

would be accepted and overwritten by 200. Then, after a 
DIAL statement has been accepted, the system would prompt 
the author by displaying 210. 



3 A ^ . 

A numbering scheme allowing decimal points was 
re j ected to conserve precious CRT space . 
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Although statements in a DIAL program may be entered 
in any order., their order for execution is determined by 
their numbers . 

The role of the statement-numbering mechanisms is thus 
twofold : 

(1) it serves to indicate that code entered by an 
author has been accepted as error-free by the 
compiler. This is signalled by the system 
displaying the next statement number and 
enabling the keyboard. 

(2) as an editing facility: statements may be 
replaced, deleted or inserted by preceding 
a statement with the appropriate statement 
number . 

The CRT screen format is shown in Figure 5.4. The 
first seventeen lines of the screen are available to an 
author for entering statements. Line 18 displays the 
light pen buttons, and lines 19 tind 2C are used to display 
diagnostics given by the compiler or command language 
interpreter. The figure shows a typical diagnostic, 
with the cursor at the position at which the compiler 
thinks the error has occurred. When an author has used 
down through line 17 of the screen, the CAI System clears 
the screen and resumes at line 1. This action is known as 
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Figure 5.4 -- The cathode-ray tube screen format 

in author mode . 
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throwing and can be forced by pointing at the light pen 
function *THR0W*. 

To view the execution of a segment of his lesson 5 an 
author types )xeq m,n, where m and n are the statement 
numbers delimiting the segment. The other options for the 
)xeq command are: 

)xeq m begin execution at m and end at the highest 
number known in the lesson 

)xeq m. execute statement m only 

)xeq begin execution at the lowest statement 

number 

The parameters m and n can be DIAL labels as well as 
statement numbers . 

Execution of a program segment can be terminated by 
the author entering )stop. Of course the keyboard must 
be enabled for him to do this , and it will be so whenever 
his program is expecting a student input . 

When an author has fully tested a lesson he attaches 
it to a course by the command 

) attach lesson-name to course-name 
The lesson then becomes inaccessible to him in author mode. 
If he wants to keep an accessible copy for himself, he can 
do so by using the command 

) rename new-lesson-name 
which will make a copy of the lesson currently loaded 
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and name the copy new-lesson-name. 

A group of one or more DIAL statements may be 
retrieved from a library and included in a DIAL lesson 
by the )include command. Two libraries are available 
to an author, his own and the public library to which 
all authors have access. The )include command has two 
forms 

) include group-name 
and ) include group-name public 

There are no structural restrictions on the DIAL 
statements which constitute a group, e.g., the group need 
not be a subroutine. A group is put into a library by 

) group group-name 



th 



group of DIAL statements 



) endgroup 
The form 

) group group-name public 
is used for the public library. 

As an example, consider a set of character constants 
an author would like to use in each lesson in a course 
he is building but wishes to avoid entering them for each 



new lesson. The group would be placed in the library by 
)GR0UP CCONS 

10 0 /^character constants:-'**/ 

110 / * * * * * * * * ft * * ft * * * A ft A rt A ;V * / 

120 0BS= 'Observe the slide above T 
130 PINT= f PRESS INT TO CONTINUE 1 
140 TYN0= 1 Type yes or no f 
150 

) endgroup 

and ) inclusion followed by a )listing 
900 
910 

)INCLUDE CCONS 
)LIST 900 

would appear as 

900 
910 

920 /^character constants:-"/ 
9 30 /**ft**ft*A***ft******»'feftAft* / 

940 - 0BS= 'Observe the slide above 1 
950 PINT- 'PRESS INT TO CONTINUE 1 
960 TYN0= 1 Type yes or no 1 
970 



The remaining commands and their functions are: 
)load lesson-name locates the named DIAL lesson in the 

author 1 s directory and by loading it 
makes it available for him to work on, 
)list m,n displays the program segment delimited 

by statement numbers m and n. If more 
than seventeen screen lines are con- 
tained in the segment 5 it is shown in 
successive batches of 17, the author 
pressing INT to obtain the next batch. 
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Thus the author can quickly tf page 
through" a DIAL lesson. The options 
)list m, )list m. and Hist are 
available and the scopes are the 
same as for )xeq. 

)delete m,n deletes the program segment delimited 

by m and n. The options of )xeq are 
available . 

)reseq m, n from p by q 

Insertions and corrections often uake th 
the final form of a program consider- 
ably different from that of its early 
stages. To avoid the inconvenience 
that this can cause , e.g., in trying to 
insert a ^statement between 1004 and 
1005, the )reseq command is provided. 
The command resequences the program 
segment delimited by m and n beginning 
with p and using q as increment. 

)directory lists all lessons in the author 1 s 

directory . 

)number The command is overwritten with the 

next free statement number for the 
lesson loaded* 
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)purge lesson-name Purges the lesson from the system. 

Since the^ actions performed by this 
command are irrevocable, a response 
is sent in struct in g an author to 
repeat the command; then, if he does 5 
the purging is carried out. 

) print [less on -name ] Produces a printed listing on the host 

computer. If no lesson-name is given, 
the lesson currently loaded is 
printed . 

)lid The command is overwritten with the 

name (ID) of the lesson current ly 
loaded. 

)off Invokes the sign-off procedure and 

hence termination of the session. 

A summary of the commands is given in Figure 5.5. Three- 
letter abbreviations for each of the commands are 
acceptable. The commands may be entered in upper or 
lower case. 

Reading from the screen 

Whenever the keyboard is enabled, an author is free 
to move the cursor to any of the 800 character positions. 
But the CHAT interface uses the cursor position to define 
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AUTHOR COMMANDS 


Function 




Command 


Other Options 


sign off 




)off 




new lesson 




)lesson <> 




listing 




Hist 
)print 


)list m 
)list m. 
)list m,n 


execution 




) xeq 
)stop 


)xeq m 
) xeq m. 
)xeq m,n 


general 




)load <> 
)lid 
)m,n 
)number 




lesson/ course 
structuring 


)directory 
)rename <> 
) attach <> to <> 
)purge <> 




editing 




)deJ.ete 

)reseq i,j from k 


) delete m 
)delete m. 
)delete m,n 
by I 


library 




)include <> 
) group 
)endgroup 




Notes: 1. 
1 2. 

3. 

i 

i 5 - 


<> is a lesson or course name . 

m and n are statement numbers or labels. 

i?j 5 k 5 and I are statement numbers. 

Three letter abbreviations of the commands 

are acceptable . 

Either upper or lower case can be used for 
the .commands • 



Figure 5.5 — The summary sheet of commands for work 

station use. 

0 

ERJ.C 
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which part of the screen will be transmitted to the CAI 
System as author input. Hence it was necessary to estab- 
lish a convention for reading from the screen. 

A window is that part of the CRT which the CAI 
System will read. Changes made or new text entered by an 
author will be effective only in this window. 

The system expects the window to contain either a 
DIAL statement or a command and will respond with a 
diagnostic message otherwise, 

After processing the contents of a window, the system 
tries to anticipate the type of the next action and 
positions the cursor in the row of the new window top. 
The end of the window is the position of the cursor when 
the author depresses INT to send his action to the system. 

The window may be moved by an author at any time, 
for example, to cover a DIAL statement further up the 
screen, by pointing the light pen to the row he wants to 
be the new window top. 

To summarize, screen reading is defined by a window 



(2) of variable size (1 to 17 rows) according to the 
length of the author action it contains, 



(1) of shape 




9 
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(3) with its top being the row where the cursor 

was left b} the system (anticipated next move 
or in response to a move window request), 
(4-) with its end being the cursor positiDn when 

IN.T is depressed. 
When DIAL statements are being entered sequentially 
the window top moves down after each statement has been 
accepted. During editing an author will move the window 
to cover a statement in a segment he has ) listed. 

The action of the light pen function *THR0W* can be 
recast in terms of the window - a throw request causes the 
screen to be cleared and the window , with its current 
contents , to be repositioned with its top at row 1. 

The *SUBST* function 

A text manipulation facility is available to an 
author, with which he uses the light pen to point to parts 
of his program at which he wishes to substitute, insert, 
or delete text. To use this facility he first points at 
*SUBST* with the light pen. The system then displays 
the prompt TEXT? on row 18 (overwriting SUBST in green) 
and positions the cursor at the beginning of row 19 in- 
viting him to enter the text. When he has entered the 
text, he presses INT, is asked FROM? and points to a 
position on the screen; then he is asked TO? The system 



150 



inserts the text, restores the *SUBST* button, and enables 
the keyboard again. 

The *SUBST* function can also be used to delete text 
if a null string is entered. In summary, the protocol 
for *SUBST* is 

(1) pen *SUBST* 

(2) ' TEXT? - if author enters nothing, then a delete 

function occurs , 
- if author enters non-null, then a sub- 
stitute or insert function occurs, 

(3) FROM? - start of replaced text, 
(tf) TO? - end of replaced text. 

5 . 6 The execution of an instructional program - student 
use of the system 

Because the current design is strictly author- 
controlled CAI , there is only one' system command avail- 
able to the student, namely 

)off 

All other responses from the student are elicited by the 
author, and take the form of typed input or light pen 
input. Figure 5.6 shows the CRT and slide displays 
during a typical student interaction. 
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The point in a lesson at which a student is restarted 

at each new session has received special attention in the 

system design • Unless the previous ses s ion terminated 

abnormally 5 the system goes through the RESUME process in 

which the student is restarted at an author-specified 

point in a lesson. To help the student's orientation, 

this point is usually at a frame just prior to the end 

of the last session . The system message displayed to 

indicate a RESUME is 

NORMAL RESUMPTION — YOU ARE RESUMING 
LESSON c AT A SUITABLE POINT 
PRIOR TO WHERE YOU SIGNED OFF. 

If the previous session terminated abnormally, the system 

goes through the RECOVER process, in which the student is 

restarted at the point at which recovery information was 

last taken. The system message displayed to indicate 

a RECOVER is 

ABNORMAL RESUMPTION — YOU ARE RESUMING 
IN LESSON b AT A POINT JUST PRIOR 
TO SYSTEM FAILURE. 

Thus during each session the system needs to periodically 
copy RESUME and RECOVER information to CAIFILES . At sign- 
on, to choose between the two processes, the system uses 
the setting of the switch RECOVNEEDED on the student record 
file STUREC. The logic of its settings is given in 
Figure 5.7. 



START 
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Figure 5 . 7 — The logic for setting the RECOVNEEDED 

switch . 



5.7 Proctor facilities 



A third type of user of the system is the proctor, 
who is present in the CAI Center building during all 
student sessions, and has both administrative and peda- 
gogical roles. To date we have examined only his 
administrative duties, where, for example, he is 
responsible for introducing new students to the system 
(by entering the student's identification number on to 
the student record file and teaching him to operate the 
work station) and dealing with operational difficulties 
during student sessions. In his pedagogical role the 
proctor is the on-site representative of an author; 
this thesis does not examine this role. 

The proctor terminal is a standard Type 33 ASR Tele- 
type located in' the proctor office. A current implemen- 
tation restriction that prevents communication between 
sub-tasks in the CAI region, in particular between the 
proctor sub-task and a student sub-task, consequently 
prevents real-time .interaction between the proctor and the 
student via the system. Interaction of this type could, 
for example, cause the proctor terminal to type a message 
that a given student had reached a RESUME point in the 
instructional program. Abnormal conditions such as 
student station failure or the student entering proctor 
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mode, could also be signaled. 
5,7.1 Proctor override 

A facility is provided whereby the proctor can 
override the normal sequence of execution of an 
instructional program. Our Phase I experience clearly 
revealed the need for this facility 

(1) to correct situations caused by hardware and 
software failures , 
and ( 2 ) to enable the student to repeat a particular 

segment of the course. 
Although the RESUME and RECOVER processes should handle 
most of the problems , I feel there is st ill a need /;or 
an override mechanism. 

The proctor can use this mechanism at any ste.ge in a 
student session after sign-on by entering )proctor on 
the display. The system responds with )_ and tne 
proctor then completes 

) override statement -number 
where statement-number is the DIAL aource-code statement 
in the current lesson at which he wants program execution 



This situation is intimately involved with the 
instructional process and, like other forms of pedagogica 
assistance given by the proctor, must be strictly con- 
trolled in any experiment aimed at evaluation of CAI . 
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to be resumed. )override lesson-name causes a jump to the 
beginning of the named lesson. 

5.7.2 Administrative programs for proctor use 

These off-line programs, most of which were written 

by Robert Cannon, have facilities for 

file maintenance of STUREC, the file of student recor 
file maintenance of AUTHREC, the file of author record 
printing the log file held on CAIFILES, 

and reporting the student statistics gathered by the 
system* 

An on-line file inquiry program has been written 
by Mitchell Bassman to display the contents of a 
student 1 s STUREC^ record* The program is used at a 
student/author work station but is accessible only to 
proctors . 



CHAPTER 6 
MODIFYING AND EXTENDING DIAL - THE 
TRANSLATOR WRITING SYSTEM 



6 . 1 Introduction 

An important requirement in the design of DIAL was to 
include in its implementation the ability to modify and ex- 
tend the language. The purpose of this chapter is to give 
an understanding of the Translator Writing System to a level 
which will be helpful in assessing the flexibility of the 
implementation of DIAL. Furthermore, the chapter should 
provide a perspective for a systems programmer working with 
an author in changing the language. 

Translators for high level languages are among the 
most complex types of computer programs and hence are 
expensive to build. Research in computer science, in 
particular in formal language theory, and experience with 
existing translators have led to a better theoretical and 
practical understanding of the processes involved in 
writing translators. Translator Writing Systems are now 
available which automate major portions of the task. For an 
excellent review of the field, see [Feldman and Gries, 1958]. 
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The utility of a Translator Writing System (TWS) is 
based on the observation that most translators hav~ many 
tasks in common - scanning of source text,! syntax analysis, 
and generation of output. If these problems are solved 
once, in general form ? the writer of an individual trans- 
lator, can concentrate on that part of the jjob which is 
unique to his translator, i.e., the connection of his 
meanings (semantics) to hie forms (syntax) ^ 

The TWS built for the CAI System to erlable users to 
modify and extend DIAL is based extensively on the TWS 
designed by McKeeman and others at Stanford University. 
This latter system and the construction of ^a translator 
for the language XPL are described in LMcKeeman, et_ al . , 
19 70]. In this thesis it is referred to as", the XPL TWS. 1 

The metalanguage BNF (Backus-Naur Form) is used to 
describe the syntax of a language for which a translator 
is to be built. The semantic definition o:': the language 
consists of a set of user-written routines in the completed 
translator, where a semantic routine is called each time 
a syntactic construct has been recognized in the source 
language program being translated. 

^For a complete treatment of certain topics, I direct 
the reader to [McKeeman, et al., 19 70]. In this chapter 
it is referred to as A Compiler Generator* 
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The TWS in the CAI System ( CAI TWS) consists of 
two principal parts : 

(1) CONSTRUCTOR, 2 a translator from BNF into syntax 
tables (also called recognition tables ) used in : 

(2) COMPILER 5 a table-driven translator written in 
PL/I using user-written semantic routines. 

These two parts are shown in Figure 6.1. 

6.2 Th e compiler and the CAI System 

Each DIAL compiler is produced with the aid of the 
CAI TWS and is known as the routine COMPILER in the CAI 
System. The routine named AUTHOR converses with an author 
and, in response to a DIAL statement, invokes COMPILER as 
shown in Figure 6.2. The object code generated is a set 
of machine language instructions for a conceptual machine, 
called a delta machine. The instruction format is one- 
address. An interpreter for delta code is in the routine 
named EXECUTOR. This routine executes programs for both 
student and author modes . 



This part is called ANALYZER in A Compiler Generator 
I prefer the term construcxor from [Feldman and Gries , — ~ 
1968] to avoid confusion with the term (syntax) analysis 
in compiler construction . 
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Figure 6.1 — The two parts of the translator 
writing system. 
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Figure 6.2 — The invocation of COMPILER by the 
controlling routine AUTHOR. 
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6 . 3 The CAI translator writing, s_ys tern 
6.3.1 Introduction 

The CAI TWS differs from the XPL TWS in three 

^ 3 
respects. 

(1) Due to the lexical flowgraph notation, lexical 
analysis is less grammar dependent. 

(2) The CAI TWS uses PL/I, not XPL , for the description 
of translators . 

(3) Some a priori knowledge of the CAI language environ- 
ment has been used. 

To elaborate this third point, consider further the 
generality requirement of a TWS. Syntax analysis is 
grammar independen t (provided, of course, that the 
grammar is acceptable ) , code generation is highly grammar 
dependent and lexical analysis is normally grammar de- 
pendent. As regards lexical analysis we know, for 
example 5 that the CC-30 character set is constant, and 
that the wide variety of tokens normally encountered, 
e.g., floating point constants, will probably not be 
required in the CAI environment . 

Since these are only minor differences, A Comp iler 
Generator is still the major documentation for th °AI TWS. 

h 

Except, of course, as data for DIAL programs* 



16 3 

This a priori knowledge of the tokens to be 
encountered has reduced the extent to which SCAN ;:ust 
allow easy modification. SCAN can therefore take a 
reasonably simple approach to lexical analysis and yet, 
by the lexical flowgraph notation, be fairly independent 
of grammar changes within the DIAL environment . 

For some grammatical constructs there is a choice 
(in the construction of any compiler) between recognizing 
them in the syntax analysis phase and in the lexical 
phase. As a policy (aimed at keeping COMPILER as 
systematic as possible) the burden of all but trivial 
recognition tasks is put onto the syntax analyzer. This 
generality and sys tematization is achieved at the expense 
of efficiency, but seems worth the cost. 

Note that the recognition of an identifier, which 
has the following syntactic definition, is done by SCAN. 
<identifier> <letter> 

| <identif ierxlet ter> 
| <identif ier><digit> 

<letter> ::= A|b|.... |Z|a|b \z 

<digit> : := Q|l| . . . |9 



The length restriction (ten) is not ?,hown in this 
BNF definition. 
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Since this definition is unlikely to change as DIAL is 
extended 5 the TWS loses little in generality. 

6.3.2- CONSTRUCTOR 

The output of CONSTRUCTOR is a set of recognition 
tables in the form of PL/I DECLARE statements (with the 
INITIAL attribute used to provide table values) for the 
version of COMPILER being built. This PL/I version of the 
constructor was supplied by John Walters [1970]. 

An XPL constructor is used for most of the runs 
during debugging of the grammar expressed in BNF as it is 
much faster and produces a better grammar analysis. How- 
ever, it produces XPL declarations. Therefore the final 
run of a set of BNF is done on the PL/I version. 

CONSTRUCTOR is described in A Compiler Generato r, 
Chapters 7 and 10. 

6.3.3 COMPILER 

COMPILER is made u of three main parts: 

(1) SCAN, which performs the lexical analysis and passes 
tokens to: 

(2) ANALYZE, the main driving loop which performs the 
syntax analysis. The recognition tables from the 
constructor are read-only data for this routine, 
which upon recognizing a syntactic construct calls: 

(3) CODEGEN, the semantic routines. 






1 

Reduce by 
applying the 
production 



Figure 6.3 — The main compilation loop in COMPILER 
showing the relationship betwe' i ANALYZE, SCAN 

and CODEGEN. 
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Their interrelationships are shown in Figure 6.3. 

6.3. 3.1 ANALYZE 

This parsing algorithm is the nucleus of the TWS 
and is described in Chapters 4 and 9 of A Compiler Genera - 
tor . The PL/I version used in COMPILER is included in 
Appendix D to this thesis. It is based on a PL/I version 
by Walters [1970]. 

5.3.3.2 The lexical flowgraph 

So thc.t SCAN could be changed easily, a notation 
was developed for describing lexical analys is . 

Cheatham's lexical graph [1967] has been modified 
so that advantage can be taken of certain properties of 
DIAL and so that there is a close correspondence between 
the lexical flowgraph and the actual PL/I code used in 
COMPILER. 

A lexical flowgraph is a collection of nodes, 
directed line segments and labels; recognition of a token 
consists of a successful traversal of the flowgraph from 



Before the complete notation is introduced, consider 
a simple example . The recognition of the terminal symbol 
<identi.f ier> , whose syntactic definition was given in 
Section 6.3.1, can be described by the following flowgraph. 



the rode 




to a node [ | . 
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/ 
/ 



\ 



T = 




Starting at [SJ , with register I set to nul. , an alphabetic 



character (class a) causes a move to the second node and 
Concatenates the character into register I. Then the 
graph loops on the second node, concatenating alphabetic 
characters and numeric characters (class n) into I, until 
another class of symbol appears. Tl- i the traversal is 
complete at node | | where 2 is placed into 'the Type 
register to signify < identified . 

There are three parts of the notation: 
(1) Phrase structure 2 ramjnar notation 

the set of non-terminal symbols. 

Vm the set of terminal symbols, i.e., terminals as 



far as ANALYZE is concerned and hence sometimes 



referred to as tokens. 



Tl 



the set of direct terminals . A direct terminal 



is a terminal wh ich is recognized directly by 



SCAN , e.g., GOTO, +, and <=. 
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the set of derived terminals, A deiived 
terminal is one which is derived according to 
some rule operating on elements of the 
character set, e.g., <text constant>. 
K a partition of the character set into classes: 

a - {A,B,...3Z 5 a,b,...,z} 

n = {0,1,.. .,9} 

s = {;} 

+ = {+} etc. 
A the 'Bmpty string, of length zero. 

(2) The communication registers in COMPILER 

A set of registers is filled by SCAN for use by 
other parts of the compiler. The regi sters and their 
contents for the current implementation of DIAL are: 

N BCD of number constant 

S BCD of text constant 

I BCD of <lexical identifier> 

T type (l = element of V^, 2 = <lexical identifier>, 
3=constant ) 

D constant type (non-null only for T=3; l=text, 
2=number) . 

(3) Flowgraph nodes and labels 

The start point (s) has already been seen. At (IT) 
the registers N, S, and I contain X. 
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pointer to the next character in the input 
string to be scanned. 

labels on line segments are of the form k/A 
where k z K 5s the class to which the character 
belongs, and A is the action to be caken. A 
can either be the null action o , or which 
means compose the character into register P , 
e.g. , 

o .. . a/C-j- 

means "if the character is alphabetic then 
concatenate it into the I register. M 
An unlabelled line segment means "anything not 
accounted f or . " 

denotes end of traversal. An element of V T has 
been recognized and the appropriatp codes 
entered into the registers. The convention that 
LP is always set ready for the next traversal 
has been adopted. 

the . .rmal program flowchart decision symbol. 
Figure 6 . M- shows the lexical flowgraph of the 
scanner used in an early version of DIAL . 



LP 



labels 




T=3 
p«i 

(text 

constant) 



Note: Certain elements of »e.g.,<- 
and^=, are not recognized by this simple 
version. The current version recognizes 
them by extra lire segments on the /Cj 
path leaving ^P) . 



Figure G.4 — A lexical flowgraph for an e cly 
version of DIAL. 
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6.3.3.3 CODEGEN 

Recall from Figure 6.3 that CODEGEN is called by the 
main compilation loop just before each reduction is done. 
CODEGEN is highly systematic and modular: to each pro- 
duction in the grammar there correspDnds one code 
section. Figure 6 . 5 shows code sections for three 
productions in a recent version of DIAL. Many of these 
code sections remain completely unchanged as DIAL is 
extended. 

6 , >+ Steps in using the CAI translator writing system 

A systems programmer using the TWS has available to 
him the program listings and other documentation in the 
Systems Programmer Manual [Mudge, 1972 3. The following 
is just a list of the steps he will follow in modifying 
anc extending DIAL. 

6 

(1) Express the grammer in BNF. 

(2) Debug the grammar using the XPL constructor. 

(3) Make a final run with the PL/ I CONSTRUCTOR to punch 
recognition tables • 



Inexpressables are handled in the usual ad hoc way 
by code in COMPILER (mainly in CODEGEN). 



PI < : 

/• IH <HATCH I R IM Art Y > 



<XMAR CON.i f> 



*/ 



CALL PMIT ( READT,Q) ; 

CALL EniT(COhPAR£LIT,TO.-._lNPG2) ; 

DO REP: /* INSERT THE JE INSTRUCTION IN THE CHAIN AND EMIT IT •/ 
/•*• SINCE *E WON»T KNOW THE JUMP ADDhESS FCR JE UNTIL WE BEACH THB ••/ 
/♦•* L A b EL A T THE END OF THr, STATEMENT, WE HAVE A REJ.CHAIN LINKING*"/ 
/•*• ALL THESE JE INSTRUCTIONS. THUS DO_ R BP HERE INSERTS THE JE IN ♦•♦/ 
/••• THE CHAIN. •••/ 
I = PEF^PTH ; 

REF_PTR~= P_COUNTER FR E£__I NS FN ; 

IF « FIRST THEN DU ; /•FIRST <OPERAND> SO SIGNIFY END OF CHAIN */ 
I = 0; 

M_ P I RST = • 0*B; 
END; 

CALL EM I T (JE , I) ; 

PETIT PN ; 



PI (HQ) : 

/♦ UO <UOTO ST> :;= C^OTU> <IDEU£1 PiER> */ 

/*** NOTE THAT THIS CODE IS ALSO JUMPED TO FROM < LA6 EL LIST> PRODNS.*/ 

IF TOS_TYPK ' 9 THEN DO; /♦PREVIOUSLY DEFINED L». BEL 50 EMIT THE •/ 
/•COMPLETE IHSTBUCTIOU. •/ 
CALL EMIT (J JM P, TOS_ADCfl) ; 
RETUR N; 
END; 

IP TOS_TYPE - 0 THEN DO ; /*IT IS THE FIRST REFERENCE TO A FORWARD */ 

/• LA^EL SO INITIALIZE THE FIXUF CHAIN. •/ 
CALL b'!UT (JUrtP.O) ; /»ZE«C - END OF CHAIN •/ 
ADDR iTOS^'i NF02) = P^COUNTfcR + (FREE_ INSTN- 1) ; 

/• FCIH1 TO THIS *-:nD ELEMENT OF THE CHAIN. •/ 

/* NOTE THAT P^COUNTER REFERENCES THE 0 OP-*/ 
/♦ CODE INSTRUCTION PREFIXED TO TEMP_I NSTNS •/ 
/♦ BY AUl'HOS. POR GOTO STATEMENTS, •/ 
/♦ (FREfc_IFSTN-l> HILL ALWAYS BE 1- FOR •/ 
/* PRODUCTIONS, 2. G, , < LA PEL LIST>, WHICH •/ 
/• JUMP HERE, tPSEE_:.NSTN-1) W ILL ONLY BE */ 
/» 1 POR THE FIRST LABEL IN THE LABEL LIST.*/ 

TYPE (TOS^I NFU2) = 10; /^INDICATE IT IS A LABEL •/ 



/♦NOW NEEDING FIXUP. •/ 

RETURN ; 
END; 

IF TOS_TYPE = 10 THEN DO; /* IT IS ANOTHER FORWARD REFERENCE •/ 
CALL EMIT (JUMP, TOS^ADDR) ; /• A DD EL 1 T TO CHAIN •/ 
ADDR (TOS_INFG2) - P~COUNTER »- (FR£E_INSTN- 1) ; 

/♦POINT TO THIS LAST ELEMENT ADDED. •/ 
/••♦ SEE NOTE ABOVE FOR TOS_Ti D i. - 0. ♦*•••/ 
RETUR N; 
END; 

ERROR = 2b; /•CONFLICTING ATTRX BUTE — IDENTIFIER NOT A LABEL. ♦/ 
RETURN ; 

Pf (41) : 

/• U\ <ASSIGN ST> <VAR> <A RRUH > <LOGICEX> •/ 

/•* CHECK TYPE COMPATIBILITY • / 



J=C_SYrt_DOPE.TYPE{STACK, INF02(SP- 2)) ; 

IF J=1 THEN IP TOS_lNFO-.=T_TexT ' HEN ERK0R=E13; 

i LSE; 

ELSE IP J^ 1 * THEN IF TOS^I/ FG-« = T_I NTEG ER THEN ERROR=E 1 M; 

ELSE; 

l'LSc IF J=b /HEN IP TOS_INPO-.=T_SLIDE 
THEN ERROR-E15; 
ELSE; 
ELSE ER.BO R= E2 7 ; 

It RRROR^=0 THEN RPTb'Li?; 

J = C_S\rt_DOPE.ADDR(SrACK.lNP02(SP-2)) ; 



IF TOS^INFO * T_TEXT T aN CALL EMIT (STOREC H, J) ; 

IF TOS_INFO « T_ SLIDE MEN CALL EM IT (STX S , J) ; 

IF TOS INFO = T_ IN TEGER THEN CALL EMIT (STX, J) ; 
RETURN; 



ri>MJM! C . I) -- The CODL'GHW ju^ t ion:; curro^poinJing to t hro., 
production;; in <i recent v».Tj;ion ol 1)1 AL 



(4) If necessary modify SCAN (by hand) in accord with 
the conventions of the lexical flowgraph. 7 

(5) Put the new recognition tables in PARSER 8 and run it 
with some DIAL source. 

(6) Go back to step (2) if PARSER runs reveal a problem. 

(7) Write the new parts of CO DEGEN and debug piece by 
piece . 

(8) If necessary, write additions to EXECUTOR'S delta 
code interpreted and debug piece by piece. 

(9) Perform final test. 

6.5 The clas s of grammars acc eptable to the translator 
writing system 

A grammar is acceptable to the TWS if it is accept- 
able to the syntax analysis algorithm in COMPILER . The 
algorithm used is a Mixed Strategy Parsing (MSP) 
algorithm of degree (2,1,1,1) according Lo McKeeman's 
definition. The "N-sks of describing in detail the parsing 
algorithm and of giving an adequate explanation of the 
degree are beyond the scope of this thesis. Chapter 4 of 



In most cases , the only changes will be to t.'ie 
symbol table routine in SCAN, 

This a routine in the CAI TWS which performs 
lexical and s;yntax analysis only. It prints a parse 
trace and is useful in planning CODEGEH. 
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A Compiler Generator gives several parsing algorithms 
and the rationale for the MSP approach- 

It suffices to say here that the class of acceptable 
grammars is large because grammars which are bounded 
context of degree (2,1) are allowed , but the algorithm 
does not suffer from the inefficiency usually associated 
with extended precedence grammars . The improvement 

t 

results from the mixed strategy approach: it uses a' 
degree (1,1) stacking decision function with three 
values ( >! stack", "don't stack" and "conflict") and 
reverts to a (2,1) predicate only for pairs where the 
(1,1) predicate is undefined. The central idea of the 
MSP algorithm, then, is to use simple (small) tables to 
make as many decisions; as possible but to extend the 
class of acceptable grammars by using more complex 
tables for the exceptional cases. 

In practice, a user wishing to implement his own 
language will use the constructor and Chapter 7 
("Programming in BNF" ) of A Compiler Generator as aids 
to obtaining an acceptable grammer. 



CHAPTER 7 
EXPERIMENTAL METHOD AND RESULTS 



Introducti 



on 



This chapter evaluates the CAI System in use in the 
actual environment for which it was designed. 

Some systems are easier to evaluate than others: with 
compilers , time and space are measurable; with information 
retrieval systems, precision and recall are good measures. 
However, programming languages and man-machine environments 
are difficult to evaluate. Validating a system whose 
single consistent design aim was ease of use is especially 
difficult. This is because of the large number and 
diversity of human factors involved and the lack of objec- 
tive measures . 

The approach taken was to make systematic observations 
both quantitative and qualitative, of student and author 
use of the system. 

In the latter part of Summer, 197 2, F. P. E *ooks , Jr., 
Chairman of the Department of Computer Science, as course 
author, programmed course material for the subject matter 
taught in the first four weeks of COMP 18 and 19. These 
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two course numbers are the humanities and social science 
sections of the beginning programming course taken for 
credit at the University. In the Fall one complete class 
section of 22 students took *f~he CAI course. The class was 
the test group in a controlled experiment to compare 
learning performance on the CAI System with conventional 
classroom instruction. 

The Fall experience was so encouraging that in the 
following semester, Spring 197-3, the CAI System was used 
for production teaching of three classes totalling 79 
students . 

The combined Fall and Spring use represents 
student hours of online production use of the system. 
This figure does not include those sessions of students 
who dropped or students from courses other than COMP 18 
and 19. 

7 . 2 Collection of student use data 
7.2.1 Experimental design 

7.2.1.1 The objective of the experiment was to determine 
whether, for the particular subject matter 5 students re- 
ceiving instruction via the CAI System achieved equal or 
better learning performance than those receiving conven- 
tional c las s room instruction . 
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If the learning performance could be shown to be at 
least as good, or better, then this would validate the 
design of the student-system interface. Furthermore, the 
Computer Science department would adept the system for 
routine teaching of several sections of COMP 18 and 19. 

7.2.1.2 The score on a posttest, a 50-minute, in-class, 
closed-book examination on the subject matter, was the 
measure to be used in formulating statistical hypotheses. 
Appendix C contains the examination. 



7.2.1.3 The methods of instruction , two similar versions 
of conventional teaching and one of CAI , wore assigned to 
cnmple^e classes as follows . 



Methods 




Control 


CAI 


Instructor 1 


Instructor 2 


Experimental 
Units 




Class 1 

(COMP 18-3 , 
218X-1) 


Class 2 
(COMP 18-1) 


Class 3 

(COMP 18-2, 
218X-2 , 
19, 219X) 



The first two classes were control groups*, the 
third was the test group. 
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The conventional method 

The usual procedure for teaching the course was 
followed: the instructors were graduate students in the 
Computer Science department; they conducted three 50-minute 
lecture-periods each week; and designed and graded their 
own assignments. 

The CM method 

The students received all formal instruction via the 
CAI System in the CAI Center. A weekly, optional-attend- 
ance question period was provided by the instructor in 
charge of the class. Assignments were designed jointly by 
the course author and instructor and graded by the 
instructor . 

At the first class meeting the course author was 
introduced to the students. ^ He addressed the class on 
the expected advantages, e.g., individualization, of CAI 
and discussed its answer analysis limitations. A good 
rapport was observed. 

Work station resources were allocated as follows. 
Three concurrent hour slots from 9 a.m. to 5 p.m. were 
available for student use, except for the first week when 

^1 vIpw this student-author link as an important 
human factor in a potentially depersonalized form of 
instructic \. 
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two stations were available. As back-up there was one 
complete work station and two other complete CC-3 0 
terminals. Stations were scheduled on a student signup 
board. Each student was allowed to sign up for no more 
than two sessions per week. 

One proctor, drawn from a roster of three, was on 
duty at all times. For experimental control reasons the 
proctor was not allowed to answer subject matter questions 
when called by a student. His function was to adminis- 
trate and to assist the students when system hardware 
or software problems arose. A proexor log of problems 
was kept. At the end of each session a student received, 
from the proctor, copies of the slides shown in that 
session . 



The CAI course had the following lessons. 



Lessons 



Subj ects 



al 
a2 
a3 
a*4 



The basic objects (integers and charac- 
ter strings), creation of variables 
(declarations) , and assigning 
values to them (assignment). 



bl 
b2 



The basic operations on integers 
and character strings. 



c 



A complete program and basic 
input/ output . 



d 



Looping by D0--loop. 



e 



IF-THEN-ELSE for decisions and branching. 



f 



Documentation , nested DO - loops , 



and nested IF-THEN-ELSE . 
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The subdivisions within lessons a and b were 
necessitated by a software bug which constrained the 
maximum size of a lesson. This was corrected by the time 
lesson c was written. 

7.2.1.4 Most experiments include undesired sources of 
variation which may affect the value of the variable being 
measured. In this experiment the identifiable extraneous 
variables were controlled as follows. 

(1) Teaching ability of instructors 

This variable was controlled by using different 
instructors for the two control groups. 

(2) subject matter coverage 

The two control group instructors and the CAI 
course author agreed on a common syllabus. 

(3 ) Posttest 

The questions on the examination came from 
four sources in approximately equal proportion - the 
two control group instructors 5 the course author 5 
and the instructor in charge of the CAI class. The 
originator of a question graded that question for 
all students. Students 1 answer sheets were identi- 
fied by a number only, so that the graders could not 
tell to which class they belonged. 
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(4) Hawthorne effect 

The students in all three classes were told that 
they were involved in an experiment to compare 
different teaching methods. 

(5) "New gadget" effect 

This variable was ignored • 

(6) Inherent variability between students 
Students vary, of course, in intelligence, 

attitude, year in school, aptitude, and other traits 
which may affect learning performance. At course 
registration time, that is, when students were 
choo sing courses for the coming - semester , they knew 
neither that an experiment was to be conducted nor 
that a new method of instruction was to be used. 
The assumption was made therefore that students were 
assigned randomly to the three classes . 

(7) Prior knowledge of the subject matter 

Based on a cursory study of students in previous 
classes, this was assumed to be negligible for all 
students . 

(8) Scientific bias of investigator 

I disqualified myself from proctor duty, grading 
the examinations , and other pedagogical contact with 
the students . 



7.2.1.5 Sample Size 

The sample size of approx-lm ately 20 seemed to be 
adequate to justify the assumptions of normality to be 
usea in the analysis of the data 

7.2.2 The questionnaires 

The quest ionnaires were intended to provide data 
to substantiate the assumptions made about student char- 
acteristics, for qualitative evaluation of the design of 
the CAI System 5 for improving the authc ,f s course material, 
and for improving the organizational aspects of production 
teaching . 

Appendices A and B contain the two questionnaires. 
Questionnaire A was completed by all three classes at the 
class meeting following the examination. 

Questionnaire B was for the CAI group only. Sections 
I, II ^ and III were completed during the same class period 
as Questionnaire A; Section IV was returned on the 
following class meeting. 

7.2.3 Production teaching in Spring 

Because the Fall experiment showed that the CAI 
System met the learning performance -criterion, as discussed 
in Section 7.3.2, the system was used for three classes 
in the Spring semester. The objective of this next use 
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of the system was to get more real experience rather than 
to conduct a controlled experiment. Because the emphasis 
was on teaching as well as possible, rather than on careful 
control for evaluation purposes , new freedoms to improve 
instruction were possible. For example , the proctors were 
allowed to answer subject-matter questions when called 
during a session. 

Specifically, this additional experience with the 
system was intended to gather more questionnaire data, 
to enlarge the set of unanticipated answers for later 
course material improvement, to evaluate the effect of 
improvements suggested by the Fall experience , and to 
subject the system to a heavier workload, namely, three 
times that of the Fall. 

Work station resources were allocated as follows. 
Four concurrent slots from 9 a.m. to 5 p.m. were avail- 
able for student use. As back-up there was one complete 
work station and two other CC-30 terminals complete 
except for slide proj ectors . Seventy nine students were 
registered on the system. 

There was one proctor, drawn from a roster of three, 
on duty at all times . During the first week, izi anticipa- 
tion of a high number of proctor calls, an additional Fall- 
experienced proctor was on duty; this extra help turned 
out to be unnecessary. 
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The same quiz and questionnaires were used. Several 
questions which were applicable only to the Fall, e.g., 
III. 5 on Questionnaire B, were deleted. The arrangements 
for completing the questionnaires, taking the exam and 
grading the exam were the same as for the Fall except 
that I graded the course author's question (#4) on the 
exam. Because I used the same written grading standard 
as he used in the Fall, I feel that no scientific bias 
was introduced. 

The following changes to the Fall system were made. 
(1) Course organization and CAI Center operation 

A lb minute hands-on introductory session was 
given to each student on the first day of classes. 

The role of the text book was clarified. 

Work station assignments were made on the 
student signup board by the proctor ahead of the session- 
change hour so that the students themselves could take 
over a work station . This was done to reduce the amount 
of activity on the hour. 

The constraint on the maximum number of sessions 
per week was relaxed from two to three. 
(2) Course material 

Only minor changes were made. They included 
coalescing lessons al through a4 into lesson a, and 
bl and b2 into b. "Press INT to continue when ready" 
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was added to those course messages which had been removed 
too quickly. The very few errors in the slides were 
corrected . 

( 3 ) The on-line system and work station 

No design changes were made to the CAI System 
or to the work station. 

The following implementation changes were made: 
CAIFILES v as enlarged, the routine to handle the free 
block list was changed, and some of the known bugs were 
corrected. The terminal manufacturer improved the CC-3 04 
light pen and corrected a design fault in the slide 
projector interface. 

( 4 ) The off-line system 

Extensive additions were made to improve the 
daily reporting on student activity.-' 

7 . 3 Analysis of student use data 

7.3.1 Introduction 

Results from both Fall and Spring are presented. 
However > only the Fall data are used in comparing CAI 
versus the standard method of instruction. 

7.3.2 Fall posttest scores 

The posttest scores have a maximum of 50. The mer-.ns 
and standard deviations were 
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Conventional 


CAI 


Instructor 1 


Instructor 2 


m = 34.2 
s = 10.3 


m = 31.4 
s = 10.0 


m = 34.5 
s = 10.0 


n = 16 


n = 22 


n = 21 



Because of the large standard deviations , it can be 
seen, by inspection, that the null hypothesis that there 
is no difference in learning performance cannot be 
rejected. Homogeneity of variance is also obvious by 
inspection . 

There is insufficient evidence to conclude that the 
CAI method is significantly better or significantly worse 
than the conventional method. 

If indeed the CAI method is different, I have been 
unable to detect the difference beoause of the high 
standard deviations in the scores. There is no reason 
to believe that the standard deviation would be different 
in future experiments of the same experimental design. 
Thus , in order to detect a significant difference , if such 
existed, one would need a much larger sample size* For 
example, using a one-tail Student's t-test, for a differ- 
ence in sample means of 0.5, a standard deviation of 10.0, 
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and testing at the 95% level, n would have to be at least 
2165 [Kirk, 1968] . 

7.3.3 Posttest scores for both Fall and Spring 

For completeness the Spring scores are included to 
give the following : 



Conventional 


CAI 


Instructor 1 


Instructor 2 


Fall 


Spring 


m = 34.2 
s = 10.3 
n = 16 


m = 31.4 
s = 10.0 
n = 22 


m = 34.5 
s = 10.3 
n = 21 


m = 35.0 
s - 9.5 
n = 64 



7.3.4 Time data 

The times for the CAI groups are from summaries of 
the daily log data. The control group time is computed 
as 10 lectures of 50 minutes each (I am assuming that 
each student who missed a class period spent the equiva- 
lent amount of his own time to catch up). The first class 
meeting is not included for any group. The times in 
hours and minutes are: 
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Control 




CAI 


Fall 


Spring 


constant 


mean 


4:34 


4: 01 


8 : 20 








median 


4:19 


3 : U5 




range 


2 :10-8 :43 


2 : 08-8:56 



The CAI times do not include the weekly question 
periods because it is difficult to assess the length 
and usefulness of these periods. In the Fall the periods 
terminated when student questions stopped; the three 
periods lasted approximately 20, 30 and 30 minutes. 
Moreover, the responses to question 1.14 of Questionnaire 
B cast doubt on the usefulness of the periods. The free- 
dom frr experimental control in the Spring allowed the 
instructors to raise questions for discussion. They 
discussed problem areas exposed by the proctor log and the 
daily log from the system. In addition they lectured on 
algorithm design and the mechanics of running programs and 
interpreting program listings. Each of the three periods 
was the. planned 50 minutes long. Using these figures as 
bounds we have 



Control 




CAI 






Fall 


Spring 




mean 


5 : 54 


6 : 31 


constant 








8: 20 


median 


5:39 


6 : 15 




range 


3:30-10:03 


4:38-11: 26 



I conclude , even with these conservative bounds , 

that t>e CAI method yaved most students a considerable 

o 

amount of time. 

A consequence of this time data is that the first 
part (CAI) of the next COMP 18 and 19 course will be 
collapsed from four weeks to three. In the Spring, two 
of the students completed the CAI course on the first 
day of the second week and 40 had completed it within two 
and a half weeks. The daily student report to the 
•'.instructors shows which students need to schedule axtra 
sessions . 

7.3.5 Questionnaire data 

Appendices A and B give the questionnaires and sum- 
maries of the student responses. A large portion of the 
data gathered pertains to quality of course material, 



Similar time savings have been observed at other 
CAI installations. 
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reaction to the CAI method per se } etc.; hence their 
analysis is beyond the scope of this thesis. 

The following conclusions pertain to the CAI System 
itself, as distinct from the course material. For most 
students, the system was transparent in the comrnunica .ion 
between author a^^ student. The students felt they were 
concentrating on the course material, not the system 
(QB.II.17. 3 22, and 30). The system was reliable (QB.III.4) 
and the response time was adequate most of the time 
(QB.I.17). The work station was firmly approved 
(QB.IV.5 and QB.III.16). However, QB.III.13 suggests 
that winter use requires better room ventilation . The 
mode and median times for students to get used to the 
operation of the system were both 10 minutes (QB.III.2). 
Assuming three contact hours per week, the majority of 
the students chose 2:1 as the best balance between CAI 
and in-class instruction (QB.I.15) . Other questionnaire 
data are used in Chapter 8 to substantiate the discussion 
of design decisions • 

With regard to the students 1 reactions to the CAI 
method as they experienced it in this setting, I conclude 

3 This is an abbreviation for Questionnaire B, 
Question 17 of Section II. 

4 

'Phis is an improvement over the Phase I system 
(Chapter 1) where a 1:2 ratio was chosen by the majority 
of its students . 



the following. The students enjoyed the scheduling 
freedom (QB ,1.3)3 felt they could work at their ovn pace 
(QB.II.18), and felt that it made efficient use of their 
time (QB.II.25 and QB. 11.31). ^hey disagreed with the 
statements that (1) CAI is inflexible (QB.II.35), (2) CAI 
makes learning too mechanical (QB,II.19 and QB. 11.40;, 
and (3) CAI made them tense (QB.II.23 and QB. 11,32). 

The assumptions made about differences in student 
characteristics were substantiated. Questionnaire A shows 
no substantial differences in attitude or previous computer 
experience. 

7 . 4 Author use data 

DIAL and its operational environment were first put 
to production use in the preparation of the course material 
for the Fall experiment. The course author. Brooks > used 
the following approach for each session. Before he started 
a work-station session he would prepare final draft copies 
of each slide in the lesson. This defined the concepts 
and their order of presentation. With each slide, he 
prepared the questions to be asked , but not the answer 
analysis. Then, on the system, he keyed in the actual 
questions, and composed in DIAL the answer classification, 
feedback, and program sequencing. All composing of new 
DIAL code and debugging was done on-line. 



Several problems, which were a consequence of this 
being the first use of the system, should be considered 
in interpreting the time data given below. The problems 
were : 

1. A severe deadline 

Lesson a was started on August 22 and had to be ready 
for students cn September 4. The course was completed on 
September 20. This had the following consequences: (1) the 
scheduled pre-Fall-course testing of the course material 
was not done; (2) some Fall students missed sessions because 
the next batch of material was not ready; (3) the author 
had long, often five-hour work-station sessions. 

2. Software bugs 

Software bugs are always expected in a new system; 
several minor ones were detected and corrected quickly. 
However, a bug in SOURCE, the routine which handles 
editing of an author's DIAL statements, sometimes 
scrambled the current copy of a lesson. The bug was 
elusive and the deadline intensified the anguish it 
provoked . 



5Brooks's preferred session is 2 hours. 
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3. Recompile time 

Because recompile time was long L athor avoided 
frequent recompiles and hence lost s- •■. ibility. Thirj 

implementation , not design , problem ir .ussed in 
Section 8 . 3 . 

The course consisted of 56 pages (50 lines per 
page) of DIAL program listings and 64 slides. 
The mean student time for the Fall course was 4 hours 34 
minutes. The total amount of author time, about 7 5% of 
which was spent on the CAI System, was 108 hours 3 0 minute 
Thus the number of author hours to produce one (work- 
station time) hour of course material was 24. To compare 
this with published ratios from other projects we must 
include the (estimated) time spent by author-support 
personnel. Typing the slide copy took 3 3 hours; photo- 
graphic laboratory time was 8 hours; and delivery of 
) print listings, etc., took another 10 hours. Thus the 
ratio is 159:30/4:34 or about 35 author-hours per student- 
hour. This is a f actor-of -f ive improvement over other 
reported results from systems of authoring (Section 8.3). 



CHAPTER 8 
DISCUSSION 



8 . 1 Introduction 

This thesis is concerned with des igning and building 
tools - tools to 

(1) build a CAI course for the beginning computer 
programming course at the University; 

(2) serve as a framework for CAI research; 

(3) study human factors in interactive CRT-based 
systems . 

The single consistent design aim was ease of use - 
this implies that the system should be well engineered 
as regards human factors . By minimum impedance to 
students 1 learning, the system would be attractive for 
CAI research; by being easy to use it would lower the 
cost (in author time) of preparing instructional programs. 
The quantitative data set forth in Chapter 7 will perhaps 
be less valuable to a designer of such a system than a 
set of qualitative observations, opinions, and satis- 
factions and regrets derived from experience. 
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Hence this chapter discusses some of the decisions 
weighed in designing the language and its operational 
environment and gives opinions on the results. 

8 . 2 The student -system interface 

8.2.1 This interface should be as transparent as possible 

the desired communication is between a student and an 

author via the author's instructional program. Hence the 

CAI System aims to intrude upon this communication as 

little as possible. Sackman, in reporting a large-scale 

experiment at the U.S. Air Force Academy, warns against 

complicated interfaces [Sackman , 1970:180]. 

The array of special calls 5 instructions, 
and online procedures , requiring direct inter- 
face between the user and the computer, can be 
overwhelming for many neophytes. 

The following measures were taken in the CAI System. 

Debugged work station 

The work station design was debugged over a period 
of eighteen ironths, during which time three successive 
prototypes were built. 

Simple commands for getting cm and off the system 

All that the student enters is his identification 
number- the CAI System uses it to locate the course the 
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student is taking and to set up the session using his 
position in the course. Leaving the system is achieved 
by the command )OFF. 

8.2.2 To minimize the effect of system breakdown 
(hardware or software) on a student's progress and 
attitudes , frequent recovery dumps are taken during each 
session. If the system does break down, these dumps 
enable the System to restart the student, when he next 
signs on, at a point just prior to the breakdown, without 
his having to take any special action. 

8.2.3 At all times that students are using the system a 
proctor is in the CAI Center building. The students 
requested his help, considered him essential, and approved 
of the proctor call switch (Questionnaire B III. 6, 7, and 
8). 

8.2.4 The response time of interactive systems is 

critical. Sackman's study of the SAGE air defense 

network introduces an important new conversational 

principle [Sackman ? 1967: 436]: 

Human performance in man-computer dialogue 
will vary with the similarity of the responding 
computer system to the real time exchange 
character is t ic of human conversation in situations 
closely related to the operator task environment. 
As computer response-time and message pattern 
deviate increasingly from realtime parallelism 
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with the appropriate conversational and probl em- 
solving norm , so will user performance deter iora to. 
with regard to the achievements of system goals, 
leading to increas ing compensatory , erroneous 
and maladaptive behavior toward the computer. 

In short, people are happiest and most productive when 

their interactions with computers follow the same pat^oros 

as their interactions with people . The environment be ing 

paralleled in CAI is the learning environment - a mixture 



of classroom a ad self -study . 



In a later study concerned with user character is tics 

in time-sharing systems, Sackman says [1970:27] 

Users with tasks requiring relatively small 
computations become increasingly uncomfortable 
as computer response time to their requests ex- 
tends beyond 10 seconds , and as irregularity 
and uncertainty of computer response time in- 
creases; users with problems requiring much 
computation tolerate longer intervals, up to 
as much as 10 minutes for the largest jobs. 

For example, while an author will be sympathetic to a 

longer response time if he has just entered a command, 

e.g., )RESEQ, which he knows will cause heavy file 

manipulation, the student will be always expecting a 

response time consistent with his classroom experience. 

In human conversations, people usually give some 

response to an utterance within a few seconds, even if a 

reply has to await longer thought. If this is to be 

paralleled by an interactive computer system, the same 

time patterns should be the target. It is somewhat 



more demanding than Sackman ! s 10-second figure. 
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For replies which will take longer than a few seconds 
to produce, the CAI System design requires that an immed- 
iate acknowledgement be given. For example, the pause 
between requesting CAI from the CHAT Monitor Table of 
Contents (MTOC) and the display of the sign-on message is 
eight seconds. Times up to 30 seconds have been observed 
during heavy activity on the host coraputt: 1 system. Th" 
acknowledgement 

PREPARATION FOR SIGN ON 
IS NOW TAKING PLACE 

is given. Another example is the running acknowledgement 

during the. recompile process in author mode. 

In a student session , except for sign- on and sign- of f , 
the system is providing for student execution of an in- 
structional program. The response time then is less than 
one second. When host system activity is high, response 
time varies between one and four seconds. According to 
the students (QBI.17) response time is adequate. 

To reduce the four-second response time, modifications 
must be made, not to the CAI System implementation, but to 
task dispatching in the operating system on the host com- 
puter. The relevant parameters include (1) the frequency 
of CHAT f s time slice, (2) the duration of each time-slice, 
and (3) the dispatching priority assigned to CHAT. 
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Those aspects of the CAI System implementation which 
contribute to the fast response time are : compilat ive 
rather than interpretive execution of DIAL programs, 
efficient disk access, no magnetic tape input / output , and 
adequate workspace in main memory for each active 
terminal. The Phase I system's use of ISAM datasets 
clearly showed the need for faster disk work. In the 
current implementation, course material is held on a 
file with PL/I Regional 1 organization and tiie basic 
BDAM access method. The student and author record files, 
however, are ISAM processed. Since they are used only 
at sign-on and sign-off, their slower response time is 
acceptable. The other contribution to the longer 
response time at sign-on comes from initiation of. the 
CAI System. 

The time it takes to display output once it begins 
is al^o important. My observations of the Phase I system, 
and typewriter-based CAI systems at other installations, 
have shown that students often lost interest while 
waiting for long (several hundred characters) textual 
messages to come out. Here, reading is being paralleled. 
Since a student can read faster than a typewriter can 
produce output, the waiting is a system intrusion on his 
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communication with the author. We eliminate this by our 
CRT terminal and fast communication lines. 

8.2.5 A substitute for hard copy 

Because of the transitory nature of the display on a 
CRT: a student does not have a record of his preceding 
work. However, on a typewriter terminal he does- He 
may use the hard-copy output for looking back during a 
session or for reference after the s-ession- 

During the exploratory stages in the design , I 

planned to develop special measures (initiated by student 

command) to substitute for the loss of hard copy. Later, 

however, R. 0. Dearborn in an experiment at the University 

showed that such measures may be difficult to justify 

[Dearborn, 1970: abstract]: 

Three groups of students were exposed to the 
same computer-administered programmed instruction 
in numerical differentiation with different degrees 
of acces s to the output from the typewriter terminal . 
Analysis of co-variance showed no significant 
difference on posttest scores between students who 
were allowed to keep the output and those who were 
not, nor between those students who could look back 
during the session at previous output and those 
whose view was restricted to the most recent output • 

I have not therefore provided any hard copy 

facilities for student mode. Authors, however, may obtain 

printed listings of their DIAL programs by the ) PRINT 

command; they have routinely done so. 
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The students in the class trial indicated that they 
would have liked printed copies of the questions and 
answers (Questionnaire B 5 1.9). 

8 . 3 The author- system interface 

8.3.1 Author experience 

8.3.1.1 One of the a priori design decisions (Chapter 3) 
was that authors would be the experienced master teachers 
themselves 5 without intermediary coders. The potential 
tutorial power of such a system is only realized when the 
master teacher himself sits at it and brings his ex- 
perienced intuition into the detailed interplay with the 
conceptions and misconceptions of his students. This 
has far reaching cons equences for system design . ^ 

1. The system must be so simple that he can use it. 

Because the professor is an occasional user of the 
sys tern 5 he cannot j ustif y a long retraining time at the 
beginning of each period of use. Design for any occasion- 
al user faces a much more stringent requirement for 



The consequences 
for other professional 
business executives . 



apply equally to systems designed 
workers 5 for example > doctors and 



simplicity than that imposed by a full-time user, who can 
be expected to stay current in the details of even a 
complex operating procedure, 

2. The system must be so easy to use that he will use it. 

Unlike the graduate assistant, the professor can choose 
whether he will use the system. If a system has many 
idio syncrasies , is awkward , is slow , or requires him to he 
constantly referring to manuals, he will not use it. He 
will delegate the task instead. As a general criterion 3 
a system such as this is well-designed when it quickly 
becomes transparent to the user, so his whole conscious 
thought focusses on the subject matter. 

With regard to whether the author-system interface 
met its design goals, the following observations are 
significant . 

8.3.1.2 The author work pattern has been described. 
Briefly, sf'.des, text, and questions were prepared in 
advance. Less than one-fourth of the questions are 
multiple-choice; the rest require the student to construct 
a response.- Nevertheless, the system power and ease of 
use was such that Brooks composed all answer analyses and 
all DIAL code on line; most of it about as fast as he could 
(touch) type. His learning time was short. The tool 
did not intrude - he concentrated on the course material 
and the course material alone while at a work station. 



This tool transparency Is reported not only by Brooks but 
by another faculty member who observed while Brooks 
worked. The instant replay via )xeq meant that he could 
see his errors ; the system ease of use allowed him to 

correct them himself immediately and Iterative], y . Finally, 
the author-hours/student-hours ratio was a factor of five 
better than has been reported for other systems ; this is 
discussed next. 

8.3.1.3 Bunderson [1970:51] says of CAI projects: 

. . . especially those involving considerable 
text and display authoring In connection with 
the production of tutorial sequences. These 
projects can require 200, 300, or more hours 
of work on the part of a "team of authors, in- 
structional designers, programmers, and media 
specialists to produce a sequence that would take 
an average student only one hour to complete . 

To produce one student hour of course material, 
Brooks spent 24 hours; the total team time was 35 hours 
(Section 7.4). This factor-of-f ive improvement over 
Bunderson r s ratio of 20 0 is attributable to the following. 

1. Author effects 

The author is a very experienced teacher and his 
pedagogical philosophy was formulated before he began 
to write DIAL lessons. He touch-types. 
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This author experience meant that much of the usual 
course-material iteration had in effect been done over the 
years before the DIAL experiment was started. The system 
design objective, however, was precisely to h'irness such 
experience by offering the necessary level of ease-of-use. 

2. System effects 

The interactive operational environment gav'e him 
immediate feedback. There are two levels of immediacy 
in the feedback: firstly, the DIAL compiler checks each 
statement as soon as it is entered; secondly., the )xeq 
facility provides interaction with the course material 
just written. The programming and pedagogical errors 
so discovered are corrected immediately by the powerful 
editing operations. 

Good lesson library service is provided by the 
command language. 

The user-oriented design of the entire disk system 
presents a one-level store to the DIAL programmer and > 
hides all management of disk storage allocation. 

The DIAL language is also an Improvement over those 
existing languages which were studied; this is discussed 
in Section 8.3.3. 



3. Organizational effects 

An author saves much time by not having to explain 
his ideas to intermediary CAI language programmers or 
to correct their misconceptions or awkwardnesses. 

Support personnel were provided for typing the final 
slide copy 5 photographic proces s irig 5 and delivery of 
)print listings to the work station. Such support is 
helpful, no" 1 " hazardous, because it doe^ not intrude 
on the author-student interaction. 

Each of the three effects contributed to 
faster instructional program writing and debugging 
and to achieving essentially the final version on the 
first iteration. Class testing and study of the 
student errors contained in the protocols turned up 
only minor corrections to the course material 
produced on the first iteration. 
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8.3.2 The interactive environment 

8.3.2.1 Figure 8. 1 shows typical sequences of author 
actions during a s ess ion to prepare and test a lesson . 

In contrast to the systems in Chapter 2, the author 
in DIAL does not switch back and forth between creation 
and alteration modes; both are done in one mode. At all 
times ( other than when he is executing a .piece of course 
material) he has the one display format before him and he 
is free to cause any action. A right parenthesis starting 
an entry signals a command; a statement number signals a 
statement. The statement may be a new statement, an 
insertion, or a change; these are distinguished merely by 
the statement number. 

The inherent properties of the CRT are exploited 
for text editing. These properties are (1) a transient 
image and ( 2 ) a two-dimens ional format (hence pointing 
carries more information content). Any statement on the 
CRT may be changed, by establishing the window around it, 
it is not already there. Figure 8.2 shows a change being 
made to statement 536. (Since 536 was not already on the 
CRT, the author displayed it together with surrounding 
statements to provide context). If, during the change, 
extra room is needed for the enlarged 536, a -THROW- is 
requested. 
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Figure 8.1 — A typical sequence of author 

sessions . 
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Figure 8.1 — continued. 



ERIC 



bO 
•H 



o 

+J 
c 

•H 



si 
o 
<> 
<> 



si 
o 

o 

:> s: v 
o ^ 

^ o o 

d si no 
si o 

si <> 

O G>) Qj 



13 . 



CO 
CO 



O Q 



E - ' 

00 

W 
PQ E - ' 



O 
6 

0) 







o 
























o 








■M 






Q 














•H 


a) 




•H 


H 

















Figure 8.1 - 



— continued. 



210 



Author action 



System response 



)lis 534 



Display screenful of statements, 
beginning with 534 



Light-pen action as shown: 




Move window; place cursor as 536 



Change statement 53 6,c.ided by 
cursor controls 



Advance cursor to end of window; 
press INT 



Figure 8.2 A change being made to a statement. 
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The *SUBST* function has not yet been implemented; 
even without it, editing proved to be very easy and 
smooth. Thus its implementation priority has been 
lowered. 

8.3.2.2 Chapter 3 laid down certain goals for the 
interactive environment. How well are they met? 

Source level 

Inspection of the system commands shows that there 
are no commands concerned with the translation of an 
author's DIAL source to object code or with the manipu- 
lation, linking or loading of object code. All of his 
work is done at the source code level . He can therefore 
view the system as one which directly executes his DIAL 
statements. However, in explaining the response time 
variability over certain editing operations 5 one cannot 
avoid a discussion of translation. Thus, while an 
author can view conceptually the system as a DIAL machine 
if he so desires, the way he uses the system is influenced 
by the implementation; to date this phenomenon has been seen 
only with recompiling. 
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Anticipating an author's next move 

After processing the contents of a window, the System 
tries to anticipate the type (statement or command) of the 
next action. It then repositions the window and the cursor 
within it to the most convenient place and generates part 
of the next action if possible. This both saves keystrokes 
and provides a time and action cue for the author. The 
following actions are taken. The author can of course 
override by keyboard action. 



correction to statement | 
(Cursor positioned under | 
portion in error . For 
example, see Fig. 5.4.) 

next statement in j *i,r ~~ 

sequence — 

(can't predict) 

Debugging an interactive system after it has been 
programmed requires not only the usual program debugging 5 
but also a separate human-f actors debugging that cannot 
be done on paper. Human-factors debugging requires the 
system designer to use his own system and to work with a 
few typical users. Brooks's use of the system showed that 



Case anticipated 



Window, cursor, and cue 
generated by the System 



command 




CRT cursor positioning met my goal of anticipating an 
author's next move. However, it revealed a related bad 
awkwardness: )LIST as originally designed put author 
mode into a state which an author left by either ex- 
hausting the )LIST request or by entering ) FINISH. 
Furthermore, if any other command was entered while in 
this state, the system responded with a fixed-time diag- 
nostic forcing a wait of 5 seconds. It became clear 
that )FINI3H and the special in-list state were both redun- 
dant and they have s ince been removed . 

Minimizing user direction 

Wherever possible, the design attempts to relieve 
the author from having to supply direct ion to the 
sys tern. An author can be completely unaware of the 
existence of the five different logical files associated 
with each lesson - he views a lesson as a set of DIAL 
statements with a name. A directory in the File Main- 
tenance System keeps track of a lesson's location, 
protects it from other authors , and protects it from 
tampering once it has been attached to a course. Neither 
need he be concerned with the system ! s use of backing 
storage - he views his DIAL machine as a one-level- 
store machine. Another example is that all source code 
entered is automatically saved against system breakdown - 
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he does not have to request such protection. 

With the small number of functionally rich commands 
there is a price that the user must pay - he loses 
flexibility while gaining simplicity. For example 5 

(1) an author has no means of structuring his 
instructional programs and data so that they 
run more efficiently; 

(2) there is no way an author can suppress the 
disk actions necessary for saving source code. 

Such flexibility ys^ rigidity tradeoffs are made in 
any system design. The Job Control Language of OS/360 
provides an extreme example. There is a l^rge v umber of 
primitives and thus one can do almost anything; it is, 
however, difficult to use. 

E xp e r ien c e -d e p en d en c ie s 

The system is not responsive to changes in an author f s 
skill in using the system. Whether he is new to the system 
or has been using it for several months he will receive the 
same level of diagnostic messages . Although this may annoy 
the experienced author, because of the speed of display of 
messages, he loses no appreciable terminal time. 
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An incremental compiler 

The design called for an incremental compiler as the 
language processor for DIAL, The possible software imple- 
mentations of a language cover a spectrum with an inter- 
preter at one end and an incremental compiler at the 
other. The current implementation of DIAL is around the 
middle of these two limits in the spectrum - a fast batch 
compiler entered interactively. There are two major files 
associated with each lesson - the source code and object 
code files. When statements are entered sequentially, 
response time has a distribution skewed over 1 'zo 5 
seconds with the mode at 2 seconds. This fast response 
time is due to overlapping disk work with user entry of 
the next statement, but, more importantly, new cocie is 
being added to the end of the existing object code file. 
However, when an out-of -sequence statement is entered, 
e.g., when an author is editing, such a change to the 
source code triggers a recompilation of the complete 
lesson and the building of a new object code file. Re- 
sponse time is then unacceptable - of the order of 2 0 
seconds for a small (40 statement ) lesson . However , 
when host computer system activity is high and a complete 
lesson must be recompiled, the author might wait 20 
minutes. The current implementation does, however, 
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provide a way of avoiding this long response time for 

each source code change. A *C* light button appears on 

2 

the author mode display format. Triggering of recom- 
pilation is suppressed by turning off *C*« Thus 
by batching his changes - entering them all with *C* off - 
he need only suffer the long response once, for his last 
change. This batching, in fact, matches how one thinks. 

Nevertheless, the long recompile time is a severe 
problem for an author: it wastes his time, he loses 
flexibility during a session because he avoids frequent 
recompiles, and it discourages him from using the system 
during high host computer system activity. Improving the 
recompile time involves a major software change which could 
not be made during Brooks's use of the system because of 
the deadline. I did, however, provide a running acknow- 
ledgement X a "statement-number odometer" ) in lieu of a 
reply; this greatly improved the human factors. 

An incremental compiler would avoid producing a new 
object code file for each source code change by structuring 
the object code file as a chained list, with each node 
being a set of object code instructions corresponding to 
one s ource code statement . This would provide 1 ' e im- 
portant fast response to author changes. It should be 



It is not shown in the Chapter 5 examples. 
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the next task undertaken in improving the implementation 
of the CAI System. Note, however, that such a chained 
structure can, by introducing another level of indirect- 
ness, result in a slower execution. So, at say )ATTACH 
time, all references should be resolved to absolute ones, 
and the code linearized, so that the execution speed is 
equivalent to the directly compiled code in the current 
implementation . 

Some reprogramming of the current implementation 
could result in a language processor closer in the 
spectrum to the incremental compiler. For example , the 
system could make some ad hoc determination of which 
parts of the object code file need not be discarded. 

An interpretive implementation , while eas ier to 
build 5 was not used because of the execution-time cost 
in student mode. 

Diagnostic messages 

When an error is detected by the system, the ease 
with which an author can determine the true cause of the 
error is important. Two classes of diagnostic messages 
exist - those caused by errors in using the system commands 
and those caused by errors detected by the compiler. The 
messages produced by the compiler when it detects a 
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semantic inconsistency have been carefully worded and 
are effective. For syntax errors, however, the 
characteristics of McKeeman ? s syntax analyzer are very 
evident - the diagnostic for the following error 

MATCH x | L7 
is ILLEGAL SYMBOL PAIR: <MJ)PLIST> _J_ 

I have not, in the current implementation, made any 
attempt to improve on such diagnostics . Improvements 
must be made, particularly on those diagnostics, e.g., 

NO PRODUCTION FOUND. IMPOSSIBLE 

TO CONTINUE PARSE, 
which do very little apart from signalling that an 
error has been detected. In practice , however, they are 
infrequent . 

A general principle for systems on top of others 
is that diagnostics from the inner system must be trans- 
lated into the terminology of the outer one before being 
fed to the user . 

8.3.2.3 The following changes were made as a result of 
human- f a ct ops deb ugging . 

1. The QAR screen division (Chapter 4) into automatically 
formatted question, answer, and response areas, was intro- 
duced into DIAL. The change was made over the weekend 
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after t.ie first week of Fall student use. This was the 
most important human-factors change. 

2. The ) FINISH command was removed. 

3. The identifier rule in DIAL was changed to allow 
lower case letters; similar] y 5 the command language 
interpreter was changed to accept lower case as well as 
upper case. 

4. The )LID command was added to help avoid erroneous 
( and di s as t r ous ) RENAME ! s . 

5. The qualifiers to the )LIST and )XEQ commands were 
changed as follows 

old dej . '.gn current esign 
m thru ... m 
m m. 
m thru n m 5 n 

In practice, the first of these turned out to be most 
frequent by far, s.o its invocation was made most succinct 

8.3.3 The language DIAL 

Here I will discuss the strengths of, the inherent 
weaknesses i n > an( 3 the current omissions from the DIAL 
language itself. 
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8.3.3.1 Strengths 

1. The language aims at ease of use by being syntactically 
consistent and by being procedure-oriented and problem- 
oriented rathe 10 than reflecting the underlying machine. 
This contrasts with many CAI languages, which are 
ess entially assembly -language level . 

The following comparative examples are used to 
illustrate this. 

Subroutine linkage mechanism 

The following Coursewriter example shows the linkage 
via return register 4 to the subroutine yesno 
Invocation : Comment : 

Id next /r4 save return address 

br yesno 
next 
qu 

Subroutine : 

yesno 

qu Type yes or no 

br rM- return to point of 

invocation 



7 7 



The equivalent DIAL code is 
Invocation : 

CALL yesno 
Subroutine : 
yesno: PROC 
• 

END yesno 

Arithmetic 

To perform the DIAL computation 
E <- (A + B + C) * D 
one would code the following in CW 

comment : 

Id cl/c5 



ad c2/c5 
ad c3/c5 
mp c4/c5 



load A (in counter 1) 
into E (counter 5) 



add B 
add C 

multiply by D 
In TUTOR one would code 



CALC F5 = Fl + F2 + F3 
CALC F, = F5 * F4 



Screen formatting 

Instead of supplying explicit screen formatting in- 
formation (row, column coordinates) as in the CW II 
example in Section 2.2.3, the DIAL author merely formats 
the display the way he wishes it to appear to a student. 



Thus the CW II example of Chapter 2 : 

dt 4* , 3// , 3/Point to the name of the animal 
dt 8 5 3// 5 3/that barks, 
dt m,10///Ddog 
dt 18,10/7 /Cleat 
dt 22,10///Drat 

in DIAL would be 

SHOWAS 

! Point to the name of the animal 
that barks . 

*dog 

*cat 

^rat r 

Branching decisions 

Contrast the mnemonic value and naturalness of the 
DIAL statement 

IF NWRONG >= 3 THEN GOTO Q5A 
to the equivalent CW statement 

br q5A//c3/ge/3, 
or the equivalent TUTOR statement 

JUMP I3,X,X,X,X,Q5A. 
Generality in naming 

In contrast to the fixed name assignments in CW, TUTOR, 
and WRITEACOURSE for counters, switches, etc., an author 
chosen identifier in DIAL can be used to name any data type 
whether it be a counter, register, switch, or buffer. 
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The naming of slides affords another example of this 
same point: 
In DIAL 

MVT=130; /-Mean Value Thm diagram */ 
• 

SHOW MVT ; 
In FOIL 
MVT=30 

TYPE *MVT 
In CW 

fp(p) 30 

Mnemonics 

(1) Machine registers or states 

CW name DIAL name 

bO ANSWER (ANS is accepted as 

equivalent) 

pO CASE 
pi SQZ 

(2) CW restart pc-'nts 

If pi 3 is on 5 then the system will restart a student 
who has been signed off at the label defined in 
return register 5. Thus, a program in CW with 
restart points would appear as 



arithl 



Id arithl/r5 



Id arith2/r5 

arith2 



In DIAL this would be 



ARITH1 ' 



ARITH2 



RESUME 



RESUME 



String manipulation for presenting text 



As pointed out in Section 2.4.2, existing languages 
have neglected the potential of a -computer for presenting 
text. Consider, however, just the simple ability to name 
an often-used text, e.g., the statement of a theorem to be 
used in several distinct paths in a frame. In DIAL this 
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would be done by 

THM = ? The theorem states 
that 



r 



THM 

THK 
SHOW THM 

With no such ability to name a character string, as is the 
case in almost all author languages, the author must type 
the complete theorem whenever he needs it in his program. 

Note however that with CW the determined author 
can avoid the retyping by using buffer storage as a 
temporary naming facility. 
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For example 

Id The theorem states that 



/ b 2 

qu 
qu 
qu b2 

However there are two restrictions on this' type of 
programming - there are only five buffers and each one 
can hold only 100 characters. Multiple constants can be 
stored in one buffer and then fetched by a substring 
operation. The program then is hardly straightforward. 

Clean syntax 

Chapter 3 argued against adapting another language, 
using the possibility of awkward syntax as one of the 
arguments. The HumRRO Project IMPACT author language 
[HumRRO, 19 70] is an extension of CW III which has better 

ERJC 
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text manipulation facilities. The awkwardness of the 
extension can be seen in this example [HumRRO , 1970:25] 

qu ((DIS D260 5 1) 5 (SET GLOS=0)) 

which is an IMPACT-Coursewriter instruction to retrieve a 
display from a text file prepared independently on a text 
editing system. 

2 . Subroutine facility 

The subroutine concept is an important contribution 
of computer science to the design of algorithmic processes 
It should be as useful in instructional programming as in 
conventional computer programming, once an author under- 
stands the invocation and parameterization mechanisms. 

3 . Text constants 

The text manipulation facilities of DIAL can be used 
for preparing text arguments for SHOW-statements . For 
example, consider the following program segment. 
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OBS <- 'Study the slide above.' 

PINT <- 'Press INT to continue when ready.' 

PENIND <- 'INDICATE YOUR ANSWER WITH THE LIGHT PEN' 



SHOW OBS, MVT /'''Show Mean Value Thm slide */ 
SHOW OBS | | PINT 

* 

SHOW OBS, PENIND 

Note that the assignment statement is only being ;^ed in 
this example to name a string of text, not to assign a 
value to a variable. Such a text appears only as read- 
only data in the program. However, once a variable is 
set up in this reentrant program c'.n ronment, it must 
be kept in each ac^ivatior record, i,e. 5 there must be 
one copy per student. 

This special nature of text data has been recognized 
and capitalized upon to improve the efficiency of the 
implementation. By using a naming-statement (=) instead 



I am referring to the reentrant program representa- 
tion of authors' DIAL programs running on the DIAL ma chine > 
not the CAI System, which is also reentrant. 

4 

In a multi-pass compiler (DIAL has a one -pass com- 
piler) this could be done without user help. 
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of assignment (<-) an author assures the compiler that the. 
target symbol is constant , not a variable, and hence 
read-only. Such text (or slide) constants become part of 
the fixed part of the reentrant program representation. 
There is only one copy no matter how many students are 
active . 

The above example then becomes 

OBS = 'Study the slide above. 1 

PINT = T Press INT to continue when ready. ! 

PENIND = 'INDICATE YOUR ANSWER WITH THE LIGHT PEN ? 



SHOW OBS, MVT 



SHOW OBS I PINT 



SHOW OBS, PENIND 



4-. The generality of a programming language 



The features in DIAL that give the generality 
mentioned in Chapter 3 are the 

(1) generality in resource allocation 

( 2 ) naming generality 

(3) PAT system matching function 
CALL statement 
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(5) character string operations 

(6) SHOWAS statement allowing arbitrary formatting 

(7) one IF-THEN-ELSE for all kinds of tests 

(8) )INCLUDE facility for library material, 

5 • Consistency 

Examples of the consistency argued for in Chapter 3 

are 

(1) modality, e.g., CASE and SQZ , are uniformly 
treated , 

(2) naming of character string and slide constants, 

(3) expressions, e.g., wherever text may appear, 
a text expression may appear. 

Note that theae measures set a precedent for con- 
sistent extensions to DIAL. 

In trying to achieve consistency I found the 
formalism of a grammar for the language to be very 
helpful. As a guide to the ease of use of a particular 
syntactical construct, I found the nu mber of productions 
to be useful. 

8*3.3.2 Weaknesses 

1. No timed response facility 

There is no provision in DIAL for an author to get 
control back from the student if he has not answered a 
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question within a certain time period. Although this is 
consistent with my main client's pedagogical philosophy of 
not wishing to pressure the student, it is a weakness in 
the language because I preclude the use of timed responses 
by other authors. 

Another author use, which is pressure-independent, for 
a timed response facility, is in tailoring the course 
material to speed of student responses . 

Note, however, that since the CHAT interface does pro- 
vide tools for these facilities, DIAL could be so extended. 
An author does have the data in the log file as to how long 
students take to answer each question. 

2. PAUSE 

The rate at which succeeding units of instructional 
program output are given depends on whether or not a user 
response separates the units . W'aen there is no intervening 
response, an author must be sure that PAUSE is set 
appropriately and so has to make the (sometimes difficult) 
judgment on how long the average student will take to 
read a unit. He may not, however, agree with this style 
of progressing a student, and instead, prefer that the 
student indicate when he is ready for the next unit. 
Perhaps a new statement is needed in DIAL, one which 
displays 'Press INT to continue when ready 1 . The same 
effect can be achieved in the current design, not by a 
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special statement, but by a CALL to procedure INT, where 
INT is defined as: 

INT: PROC 
REPEAT 

S 1 Press INT to continue when ready, 1 
UNTIL PAT( 1 1 ) 
END INT 

Class use showed in fact that such student-initiated 
progression is better. The course material was so changed 
for the Spring use. A new statement, PINT, has been 
added to DIAL; this temporary language change will remain 
until procedures have been implemented. 



3. Data types 



The dat a types in DIAL are 

text 
slide 
integer 
label . 

The data structures are scalar and vector. 

These were regarded as essential for an author 

language. Other data types, for example 

arrays - 
global text variables 
real numbers 



b Note that global text constants are provided by 
the ) INCLUDE facility. 
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are not in DIAL. The usual tradeoff between usefulness 
and cost of implementation (size of the main-memory- 
resident language translator) excluded them. 

8.3.3.3 Omissions 

The following are designed omissions* 

1. A HINT facility 

The HINT (or HELP) facility is usually designed so 
that a student may request a hint for each question pre- 
sented. Hence an author must prepare a hint action for 
each question - if he does not, the student may be 
adversely affected by the standard system response 
! N0 HINT FOR THIS QUESTION'. I prefer amplif icatory 
s equencing to be explicitly programmed . For example , 
in DIAL, use 

UNREC *, L2 5 L3 
with the code sections at L2 and L3 being amplification 
of the question. Furthermore, I believe that being able 
to request a hint or help at every interaction in a 
teacher-student dialogue is not natural. 

Notice that HINT requires an author to define two 
teaching tactics for every micro-point. As contrasted 
with such preparation of both a coarse-grained teaching 
tactic and a fine-grained one, it is less costly for the 
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author to put all students through the fine-grained one; 
and if display and response are fast, it may not be any 
more costly and tedious to the good student. (But then 
again, it may.) For the poor student, the success 
psychology is considerably better than failure psychology. 

2 . A calculation mode 

Outside of the CAI System, our students have reeady 
access to many terminals providing APL. Moreover, it 
is planned that some interactive PL/I service be a sub- 
system of CHAT. Perhaps the omission in DIAL of calc , is 
really a question of subject matter bias. Calc is impor- 
tant to PLANIT because it is directed mainly at statistics; 
the numeric tests for equivalence in PLCLS [Oldehoeft, 19693 
provide an attractive iorm of answer analysis for 
numerical analysis. The UNC CAI Project intends to add a 
facility which is attractive for answer analysis in com- 
puter programming - a PL/I language processor (Chapter 9). 

8.3.3.4 General comments 

1. The DIAL subset used 

The following are not in the current implementation 
of the DIAL language specs: vectors 5 the FRAME-sratement , 
procedures > SUBSTR, INDEX > LENGTH > and IF-THEN-ELSE . 



The language features actually used by Brooks wor^: 
naming, assignment, SHOWAS , SHOW , MATCH, PEN , PAT, 
UNREC, GOTO, RESUME, CASE, ENDLESSON. 

2 . Reserved words 

Reserved words are those appearing in the grammar, 
e\g., SHOW IF MATCH . They cannot be used in any way 
except in their intended structural use in DIAL, a con- 
sequence of the implementation based on McKeeman ! s Transla- 
tor Writing System. The effect of this limitation can be 
summarized by saying that it violates the criterion of 
modularity stated in [Radin and Rogaway , 1965]: !T . . . 
but if you don't need it you don't have to specify it or 
even learn about its existence, . . . . " as one of the de- 
sign criteria for the language PL/I. 

This criterion, however, is not really applicable 
to DIAL. There are only 40 reserved words; an author 
can learn them all, a virtually impossible task for PL/I. 

3 . Two branching statements 

Branching conditions and actions can be described 
by the IP-statement alone. However, because of the very 
frequent occurrence of 

(a) a logical expression with the ANSWER register 
y as a comparand 

ERiC 
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(b) responses which are equivalent for branching 
purpos es 

the MATCH-statement is provided to give a more compact 

notation, at the expense of mnemonic value. 

The following two DIAL program segments produce the 

same result. 

IF ANSWER = f 2A T j ANSWER = 1 2C T THEN GOTO LI 
IF ANSWER = ! 2B ? THEN GOTO L2 

MATCH ! 2A ! | ? 2C ! , LI 
MATCH ! 2B ! , L2 

4* The ) INCLUDE facility 

The des ign called for a library subroutine facility 
whereby subroutine procedures are made available in some 
library for inclusion as procedures in an author's in- 
structional program* This facility is widely accepted hi 
computing and has been used in most computer installations 
for several years* 

Rather than a library subroutine facility, the CAI 

System has the ) INCLUDE command, a facility which is 

conceptually more powerful. It is more powerful in the 

sense that arbitrary text, not just subroutines, can be 
g 

included* Moreover, it is consistent with the DIAL 



As an analogy, the PL/I compile -time ^INCLUDE will 
accept arbitrary text, whereas the OS/ 360 linkage editor 
accepts only valid subroutine procedures. 
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machine concept - an author manipulates only source 
text, not compiled code as well. 

8.3.3.5 Summary 

DIAL is an improvement over existing author 
languages. The improvements can be seen both in the 
language itself and* more importantly , in the operational 
environment in which it is embedded - an integrated, 
functionally complete system serving authors, students, 
proctors, and computer programmers. Implementation with 
a translator writing system has been seen to simplify 
the remediation of weaknesses as they are discovered. 
As can be seen, DIAL offers little new in CAI function. 
However, some general, powerful, and easily used 
mechanisms have been borrowed from general programming 
languages, and embodied in a consistent syntax to provide 
features not usually seen in CAI languages. 

8 . 4 The computer programmer - system interface 

The interface discussed is the one involved in using 
the CAI Translator Writing System. Chapter 6 should help 
the reader in his assessment of the flexibility of the 
DIAL implementation. 
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Of the three parts of a compiler for a new version 
of DIAL 5 the lexical and syntactic parts are taken care 
of by the TWS. The semantic routines, however, require 
a PL/ I programmer with knowledge of the internal structure 
of COMPILER. To assist him, the design of that routine 
is highly modular, particularly in the semantic routine 

CODEGEN . 

The CAI TWS has proved useful in the following 
situations . 

1 . Progressive implementation of a fixed design 

Several versions of DIAL, embodying progressively 
larger subsets of the specifications in Chapter 4, have 
been implemented. 

2 . Improvement in design 

The language design process did not stagnate during 
progressive implementation, and several improvements have 
occurred. One replaced the CC and SC attribute declara- 
tions by the naming statement. For example 

OBS - 'Observe the slide 1 
used to be achieved by 

DCL OBS CC 'Observe the slide 1 
This change was handled entirely at the syntactic level 
by the CAI TWS. Another improvement, but one which 



requires some semantic change, was the generalization of 
mode switching . For example 

CASE <- arithmetic-expression 
replaced the two statements 

CASEON and CASEOFF 

The CAI TWS promises to prove useful in two other situa- 
tions as well. 

3 . Correction of mistakes 

Of those mistakes discovered during human-factors 
debugging, for example, the redundancies discussed in 
Section 9.2, DIAL/2, the majority of them are correctable 
at the syntactic level. 

4- . Extension beyond specifications in Chapter M- 

This is , of course, the situation in which the TWS 
is most attractive. However, most of the computer 
programmer's work will be in writing and debugging at 
the semantic level. DIAL/ 2 1 s PARSE function is an 
example. 

DIAL/2 is a language radically different from current 
DIAL. But the differences are predominantly syntactic, 
not semantic. This further justification of a TWS 
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implementation of DIAL was unexpected because I had 
predicted that DIAL would have semantic, not syntactic, 
limitations . 

A good measure of the effectiveness of the computer 
programmer-system interface could be obtained when the 
next step in progressive implementation is taken. For 
at each step the changes are well defined. Time and 
effort data should be gathered for each of the following 
tasks , which are defined in Chapter 6: 

language definition ; 

BNF programming; 

PARSER runs ; 

writing CODEGEN additions; 

writing new delta code interpretation 
in EXECUTOR; 

debugging. 

8 . 5 Observations about human factors 

This section presents a selection of the more im- 
portant human-factors considerations involved in my 
research. I believe , but have not proved, that these 
observations are generalizable to the design of most 
man-machine interfaces . 
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rule ,r the same things should be done in the same way 
wherever they appear", they violate the psychological 
principle of unif or^ity . They will usually be more 
difficult to learn and more difficult to use without 
error . 

Several components of language are involved: 

7 

syntactic, e.g., consistency in display format ; 

semantic; pragmatic, e.g., consistency with the user's 

real-woxdd experience; stylistic, e.g., tone of messages; 

g 

and lexical, e.g., rules i r or forming abbreviations. 

A consequence of the. need for consistency is that 
instant design cannot be done; any change generally 
reverberates throughout the whole design. 

Consistency throughout is part of the conceptual 
integrity of design. This integrity is far simpler to 
achieve when there is only one system architect specifying 
all the elements of the user-system interface . Two 
designers may agree completely on principles; there will 
still be differences in style, and these differences will 
inevitably show in the micro-decisions of the design. 

The student user of the "CAI System has just one dis- 
play format, QAR, to master, from sign-HDn through instruc- 
tion to sign-off . The author has just two: QAR and the 
author-mode format . 

8 

Sometimes, to maintain consistency, a designer will 
include facilities which he predicts will never be used. 
The m,n option on )list is an example. 
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8.5.3 Sackman T s conversational principle 

This principle (Section 8.2.4) is a very useful 
guideline . 

However , response time , while critical , is not the 
only factor in paralleling human interactions. I suspect 
that because respons a time is readily measurable ( compared 
to other factors, such as command language ease-of -use ) , 
i" 1- has been overemphasized in the literature. 

8.5.4 Top-down design 

Top-down design, or outside-in in this case, helps to 
ensure that the design focus is on the man in the man- 
machine interface , not the machine or implementer . 

8.5.5 Use r- initiated progress ion 

There are now very few intervals when messages are 
displayed for a fixed time in the CAI System; in most 
cases, and always for long messages, the user, not the 
system decides when to progress. This change in philosophy 
evolved during testing. It turned out that when a 
message is displayed for a fixed time, the slow user will 
miss part of it > and the fast user will get impatient. 
If an author 1 s course material does this, it not only 
reduces individualization, but also frustrates both fast 
and slow students; the same applies to the system in which 



the course material is embedded. 

The same is true in author mode, where the messages 

are generally diagnostic messages . An experienced author 

detects the. cause of his error very quickly and wants to 

9 

get on with fixing it. 

8,5.6 Minimality - the search for powerful primitives 

As with computer architecture, programming language 
design, and command language design, the search is for 
powerful, general-purpose primitives . Sometimes these are 
found by seeking them to start with. Thus, a goal con- 
tinually pursued in this research was a single canonical 
form for answer matching. The pursuit of this goal (not 
yet achieved) led to development, for example, of the 
PAT function, which subsumes the functions of MUST, 

CANT, DIDDL, keyl, etc., found in other languages . 
Often such primitives are arrived by iteration, e.g., 
collapsing several commands into one. 

8 . 6 The cost of designing and implementing the system 

Developing the CAI System used for the Fall 1972 
class took 2358 man/hours over a period oi three years. 



Fixed-time diagnostics annoy the experienced user 
in the same way that long typewriter-terminal diagnostics 
do . 
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This includes both the design of the system presented in 
this thesis and the impl ementation and documentat :* on of 
the subset defined in the Systems Programmer Manual [Mudge, 
19 72]. It does not include the thesis writing time. 

The size of the CAI System, i.e., the on-line 
routines, at the end of August, 1972 was as follows. 
11,000 printed lines of PL/I source code 

(Including blank lines for readability) 
3,691 PL/I statements 
About 2 00 of the 3691 statements are DECLARE 's, 

almost all of which declare many identifiers, 
which leaves about 3500 statements. 
Hence, the 11,000 printed lines are made up of 
comments, blank lines, declarations, and about 3500 
executable statements . 

As with any software engineering project, the time 
includes the following activities. 

1. Building scaffolding 

Apart from the usual scaffolding there was 

a. CC-30 i/o simulator (the CHAT interface simulator) 

b. PARSER to debug the syntax analyzer and to aid 
in using the TWS 
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c. offline service routines 

- crude versions of file maintenance of STUREC, 
AUTHREC, CAIFILES 
lesson listing: an offline )PRINT command 

2. Scrapped code 

3. Project meetings 

4. Demonstrations and discussions for site visitors 

5. Systems Programmer Manual 

6. Test programs for PL/I 

learning language features new to me 

testing features obscurely described in manuals 

choosing among alternative PL/ I methods 

The time also includes the student/author work- 
station design and prototype construction. 

Because of the method I use to record my time 
(effective hours), each time figure given in this section 
should be inflated by 20% to account for coffee breaks, 
etc., if they are to be compared to industrial work hours. 

The high proportion of time spent in a project like 
this on design, tooling, and scaffolding is reflected by 
the fact that over one half of the 3500 instructions were 
written and debugged in the Fall semester of 1971. These 
1800 instructions were done in 594 hours , This was straight 
ooding and debugging after all design, scaffolding and 
data structures had been taken care of. For this sprint 



period, productivity was at a rate of about 5000 debugged 
PL/I statements/man-year* The overall project rate is 
about 2470 statements /man-year. 

8 . 7 Is it widely applicable ? 

Could another university install the CAI System? 
Could a high school install a work station with access 
to DIAL at a remote host computer? 

Given the properties of current time-sharing systems, 
the most portable system would be one which is written 
in. FORTRAN and which uses a teletype as terminal. Indeed, 
the FOIL, WRITEACOURSE and PLANIT systems of Chapter 2 
state this sort of high portability as a design requirement. 

These constraints were rejected as too rigid and 
awkward for this project, but the same sorts of 
portability were goals. 

8.7.1 Portability of the software 

( 1) The implementation language 

The CAI System is written entirely in the machine 
independent language PL/I, and in this respect it is 
highly portable. The particular implementation used is 
the F-level OS/ 360 compiler. Changes may have to be made 
to run with other PL/I environments because 
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a. some implementations are a subset of PL/I (F). 

b. the run-time environment of PL/I (F) is 
intertwined with OS/ 3 60. 

c. the machine-dependent UNSPEC function of PL/I 
is used in the CAI System. 

( 2 ) The host computer's operating system 

An absolute requirement for CHAT is OS/ 360 with the 
MVT option. Only minor changes need to be made locally. 
Without CHAT the prospective user is faced with two 
problems: communications support and multiterminal support. 
The communications support for single terminal operation 
would be reasonably inexpensive to build. This is cer- 
tainly not the case for multiterminal support, the major 
part of CHAT. 

8.7.2 The host computer 

• A medium scale computer, e.g., a S/360 Model 50, 
would provide the amount of main memory and type of disk 
backing storage needed for the on-line routines of the 
CAI System. Thus the system is expensive, but a price 
must be paid for richness of function and good perform- 
ance. Main memory usage is one copy of the reentrant 
load module (155,000 bytes) and a work space (the 
activation record) for each active user. The latter 
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is dynamically allocated by the CAI System; space is re- 
quested when needed and freed when available. This results 
in a substantial improvement in memory use over static 
allocation. However, this dynamic behavior makes measure- 
ment difficult. The lower bound of each student work-space 
is 21,000 bytes; the upper bound throughout a session is 
about 25,000 bytes except at sign-on and sign-off times 
when 42,000 bytes 10 are used. The overall utilization 
of memory could be improved if work spaces were swapped 
out during user think times; the resulting zesponse time 
degradation would not meet my design goals, however. The 
lower bound of an author work space is 10,000 bytes; the 
work space grows to 14,000 bytes when a statement is being 
compiled, and peaks at 26,0 00 bytes during author execution 
of a DIAL program. 

Schultz ! s CHAT monitor has been carefully crafted in 
assembler language and requires only 2 8,0 00 bytes* 

8.7.3 The terminal hardware 

The student/author work station is built around a 
terminal which, if not in widespread use, is commercially 
available and based on established technology. 



26,000 bytes of this are used by the OS/360 input/ 
output routines, e.g., the indexed sequential access method 
routines. They are required only at sign-on and sign-off. 
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8.7.1+ The communications hardware 

To achieve a performance consistent with the design, 
remote terminals must be linked by a line of at least 
medium speed (24-00 bits per second). Teletype-speed 
lines are certainly inadequate. Since our terminal and 
communications equipment from Computer Communications, 
Inc., can be configured flexibly (with the addition of a 
CC-70 communications processor if necessary), terminals 
in widely separated sites are possible. 



CHAPTER 9 
SUGGESTIONS FOR FUTURE WORK 



9 . 1 Introduction 

This chapter recommends several directions in which 
the present CAI System design might be extended, as well 
as presenting some research topics. Recommended improve- 
ments in the current implementation of the design are not 
discussed, as they are covered in the Systems Programmer 
Manual, 

In contrast to the spefiPB^ic suggestions in this 
chapter, the goals of Phase III of the CAI Project provide 
more general direction. Phase II 1 produced Schultz ! s CHAT 
monitor, the CAI System, and Brooks's course material. As 
the Project formulates the goals for the next phase, we 
find that we are more interested in results that teach us 
something about interactive systems in general them we are 
in attempting to devise new CAI methods and strategies as 



See Chapter 1 for its goals. 
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such. The West House facxlity will be used to investigate 
the factors in system design which make interactive CRT 
systems easy or hard to use. This includes work-station 
design, design of application-oriented languages, system 
command languages, system robustness and graceful-fail 
features, operational procedures, and integration of human 
assistants with machine systems. This thesis has investi- 
gated these factors severally, but their integration and 
interaction ultimately determines ease of use. 

The wide class performance variances observed in our 
tests show that a new methodology for evaluating such 
factors must be developed; probably it will be based on 
systematic observation of users, error-rate data, timing 
data, and user questionnaire data. 

9.2 DIAL/2 

In contrast to on-line entry of a program written 
prior to an on-line sessx^, , on-line composition places 
greater demands on a language . A much clearer understand-- 
ing of these demands came from actual use of the system. 
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Note, however, that in the pure CAI area, the Project 
has made available a proven, total, flexible system for 
teaching . Already several researchers in the University 
and in the state have shown interest in using the System 
for research in instructional programming , learning theory, 
and cost-effectiveness of CAI. 
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The proposals in this section reflect this experience and 
also the influence of Dijkstra T s structured programming 
[Dijkstra, 1970]. 

The exact syntax and semantics of the proposals are 
not given. Moreover > their smooth integration with 
current DIAL to maintain a consistent uniform design is 
not covered at all. 

9.2.1 Response sets 

The response set provides a more powerful means of 
classifying responses in a MATCH-statement . The extra 
power comes both from the increase in function and from 
its generality. A set is defined by 

set-name = <elements> . 

As an example 

MATCH set_l|set_2| < , Y , 5 !i YES ! > 5 next 
would branch to next if at least one of the elements in 
the three sets matches. 

Examples of sets are 

1. set J. = < 1 INTEGER 1 3 1 AN INTEGER' > 

2. set_2 = < ! CHARACTER STRING' , 'A CHARACTER STRING ! > 

3. setJL2 = <set_l 5 set_2> 

4. numeric = < ! 0 ! , f l' 3 f 2 T 5 ... ' 9 ? > 

5. yes = < ! Y ! , «YES f > 

ERLC 



6. oddpen = <PEN(1) 5 PEN(3), ...PEN(9)> 

7. gamma = < l DOG l 5 PAT ( ! tDOGt 1 ) , P4> 



Example 3 names a set which is the union of two other sets; 
any number of sets could form a hierarchical structure . 
The element P4 in example 7 is a subroutine which operates 
on the ANSWER register. For instance, it might be a 
general indefinite ?t ticle remover that does the work 
of examples 1 and 2 . 

Other set operations might be provided, e.g., inter- 
section, complementation , and element selection. 

Note that response sets provide a clean syntactical 
integration of the natural language processing subsystems 
of Section 9,5. 

9.2.2 The semantics of CASE 

The system log showed that students frequently entered 
PL/I statements in lower case instead of the mandatory 
upper case. An author would like to identify this error 
rather than respond with the UNREC message. He can do 
this in DIAL/1 with the CASE statement , but for this 
particular need it is clumsy. He would like to put a 
CASE switch in the body of a sieve and cause the ANSWER 
register to be retranslated. However, case translation 
would then no longer be a preprocess ing function. 
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Changing the semantics of CASE thus requires a rethinking 
of the preprocessor concept in the DIAL machine. Perhaps 
what is needed is a general function like TRANSLATE in 
PL/I which would certainly handle the CASE problem. 

9.2.3 Block structure 

Real author use of DIAL showed certain elements of 
redundancy . Consider the present typical frame 
structuring. 

SHOWAS 

MATCH response set, branch forward 
. 

MATCH response sets, branch 
MATCH 

UNREC 

branchlabel: SHOW feedback 
branch back 

. 

This shows two redundancies : 

(1) the branch to the feedback (juxtaposition would 
solve it), and 



See Figure 4.2 for a typical sieve. 
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(2) the branch from the feedback (always either back to 
the lead-MATCH or on to the next frame). 

The first is a burden not only because of the necessity 
for generating multitudes of labels 3 but also because the 
author must stack feedback messages in his memory as he 
enters the sieve response sets and then uns tack them after 
the UNREC. 

The following vertical bracketing into blocks , one 
for each sieve element, 

MATCH 

response sets 

feedback 

branch 
MATCH 

• 
• 

solves the first problem. Also 3 readability is greatly 
enhanced. The branch could be dispensed with if the 
single case of forward branching were distinguished by 
the operator , MATCHR 5 so then an implied branch back is 
part of each ordinary MATCH block. 

Most labels are obviated . DIAL/ 1 demands extensive 
use of labels 5 an annoying burden in on-line composition. 
My aim now is self-referencing branches: branches should be 
relative not abs olute . 



For example, DO -WHILE and UNREC * are self- 
referencing . 
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9.2.1 Branching functions 



Consider the following block structure 

r r- 

i — 

! I_ 



L 

with a set of branching functions which take block c as 

(explicit or implicit) arguments: 

in move in to the next contained block 

out move out to the next containing block 

up move to predecessor block on the same level 

down move to successor block on the same level 

exit move to outermost containing block, i.e., exit is 

the function composition of out's 
Then , viewing a program as a two-dimensional space, 
horizontal movement comes fro;^ the notion of depth into 
a nesting of blocks. In current DIAL, only vertical 
motion is possible: amplification of a concept, con- 
ceptually a horizontal movement, must be done by a GOTO 
Return to a lead match is also done by a GOTO, unless 
U * is used. 
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9.2.5 A small number of control structures 

DIAL/1 has specialized control structures, e.g., U *. 
Two new ones are proposed: branching functions and MATCH- 
block. While specialized control structures in a special 
purpose language can be justified on the grounds of con- 
ciseness of expression and application-orientation, 
there is the danger that the language may have such a 
diversity of different control structures that ease of 
learning and use suffer. Thus, in adding function and 
providing self-referencing branches , the aiir should be 
a small set of uniform, consistent control structures. 

9.2.6 A PARSE system matching' function (due to Brooks) 

PARSE *70uld take a grammatical specification, in RNF 
for example, as its argument and return 1 if the student's 
response parsed correctly, 0 otherwise. For example, if 
ident names a set of BNF productions for a PL/I identifier, 
then 

PARSE (ident) 

could be used in the answer analysis of a response to the 
question "Construct a valid PL/I identifier." 

9.2.7 The operational environment 

Whenever DIAL is changed, the implication T or the 
operational environment should be studied. Consider the 
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following . 

Indentation enhances the readability of block- 
structured programs. The )LIST command could reformat an 
author's statements according to the structure of DIAL as 
NEATER2 [Conrow and Smith, 1970] does for PL/I. Thus an 
author need not spend time indenting as he is entering his 
code . 

9 . 3 Author-defined commands for student use 

Currently the only command available to a student is 
)0FF. All other student inputs are in response to 
explicit directions from a DIAL program. This section 
proposes an extension to DIAL which would enable 
an author to define a set of commands for student users 
of his instructional program. 

Each, student response would be checked to see if a 
command is being given. The occurrence of a command would 
result in the execution of th^ action specification for 
that command. An author would provide a complete defini- 
tion of each command by a set of command units 5 each one 
consisting of a name and action specification. For 
example. 
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ON REVIEW DO 

SHOWAS 'Review sequences are 
available for the following 
topics . Indicate your choice 
with the light pen: 

* ARITHMETIC OPERATIONS 
ft 

» 

* No review - return to lesson' 
MATCH PEN(l) , ARITH 

• 

END 

A command unit has the form 

ON command-name action-specification 
where action-specification is a statement or a DO -group. 

If execute on of the act ion- specif ication does not 
result in a branch out of the command unit, then execution 
resumes at the SHOW-statement controlling the read. 

I suggest that such author-defined commands do not 
use the special start symbol ) since this should be 
reserved for additional system commands. An author may, 
however, wish to establish the convention that all begin 
with some other special symbol, e.g., #, $, or @. This 
would not be necessary if the rule is established that all 
MATCH-specif led responses are checked before the list of 
commands . 

A command facility would add to the ease of use of 
DIAL; to achieve the equivalent in the current design, an 
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author must specify the response in every MAT HH group, e.g. 

MATCH 1 REVIEW ' , REV 5 

Moreover, it would add flexibility to the CAI System; an 

author coulc provide foi 1 much greater student control over 

the path through a set of course material. 

As a simple example consider a command MENU: 

ON MENU DO 

SHOWAS ' Select the section you wish to 
work next : 

'''EXPRESSIONS 

'-PROGRAM STRUCTURE 

'^DECISION MAKING 

'-CHARACTER STRINGS 

'''ITERATION 

• 
• 

END 

The command MENU is roughly equivalent to g£ to^ in 
Coursewriter . 

Other examples of author-defined commands are: 

(1) a status reporting command, which would display 
certain measures of performance kept by an 
author in hi^s DIAL program. 

(2) a command by which a student can consult a 
dictionary or glossary. If the vector DEF contains 
definitions and is keyed by the vector KEY then an 
action-specification could be as follows . 



ON DEFINE DO 

L?. : SHOW 'Enter word to be defined' 
ARG <- ANSWER 
I <- 0 

LOOP: /"Linear search of keys'' 5 / 
I <- I + 1 

IF I > NDEFS THEN GOTO NOT; 

/* not found */ 
IF ARG = KEY (I ) THEN GOTO FOUND; 
GOTO LOOP; 
FOUND: 

SHOW DEF(I) ; 

GOTO EXIT; /* return to controlling */ 
/* SHOW via the default */ 

NOT : 

SHOW 'This term is not in the course 

dictionary. Perhaps you misspelled. 1 ; 

EXIT : 

END; 

The responses to Questions IV. 2 and IV. 3 on the Fall 
and Spring questionnaires show the desirability of the 
DEFINE and REVIEW facilities. 

Finally, recall the timed-response facility dis- 
cussed in Section 8.3.2.2 and notice the semantic 
similarities to the proposed author-defined commands. 
The action-specification would be 

ON TIMEUP DO 



END 

but the system rather than the student would signal the 
command . 
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9 . 4 Debugging aids for DIAL programming 

The most important debugging facility is the inter- 
active environment itself. However, this should probably 
be supplemented by seme other aids . Study is needed to 
determine what aids are necessary and how they can be 
incorporated into the CAI System in a manner consistent 
with the design philosophy. 

As a departure point for this study, the following 
could be considered. 

1. Tracing 

A step-by-step )XEQ optic : for every statement 
executed, two screen displays would appear - a debug 
screen and a student screen. The debug screen would 
display information such as 

(1) the DIAL statement executed 

(2) the values of variables, registers, etc. 
referenced in the statement. 

The author would advance such an execution with the INT 
key , with successive depressions caus ing the debug and 
student screens, to appear alternately. 

2. Value assignment 

This would enable an author to assign values to 
variables just prior to an )XEQ. 

O 
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Some aids would be added as part of the language, 
others as part of the operational environment. Some may 
be implemented by inserting checks in the object code 
(subscript checks, for example), others by a monitor 
controlling author-invoked execution. 

Attribute tables, cross-reference lists, etc., 
should be added to the listing obtained by the )PRINT 
command. 



9 . 5 Answer processing subsystems 

For certain types of constructed responses, e.g., 
when some me aning must be extracted from a typed response 
conventional author languages are sometimes not very 
powerful . As an alternative to introducing such power 
into the author language itself, this section proposes 
a study of existing computer programs for proces oing 
semantic information. Suitable programs could be attache 
as subsystems to the CAI System. 

Not only should the systems programming job of 
attaching subsystems be studied, but also the interface 
with an author through DIAL. 

9.5.1 An existing language processor for the programming 
language being used in an introductory computer program- 
ming course could be harnessed as a subsystem. It would 
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then be possible for an author to elicit a program segment 
from a student and the CAI System to pass the student's 
answer to the language processor for analysis and 
execution. The design challenge here is meaningful 
communication between the execution and the author's 
instructional program so that the student can be given 
pedagogically useful feedback . Project TEACH [Fenichel, 
19 70] has implemented and evaluated a modest subset of the 
proposed environment; the project has now launched into a 
substantial research program aimed at coming closer to the 
full environment. 

As a first step , I suggest a syntax checker > Each 
program segment would be analyzed syntactically only. A 
vehicle for this c^jld be the syntax analyzer (using a 
PL/I grammar) of the CAI TWS described in Chapter 6. 

9.5.2 The above subsystems are restricted to only one 
subject matter. To get real general power, one wants to 
incorporate natura] language processing subsystems. Al- 
though Chapter 3 argued that such systems are still too 
experimental to form the central framework for a production- 
orlentec iuthor-controlled CAI System, system developers 
must keep this goal in sight. What one really wants for 
CAI is a subsystem which matches the semantic content of 
a response against that of a single ca nonical f orm given 
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by an author. 

9 . 6 A man-machine interface for unrecognized answers 

The following man-machine system is proposed as a 
generalized unrecognized answer model for research. For 
each group of n students (n to be determined) there would 
be a tutor station consisting of a man and a special 
console . Whenever a student response was not recogni zed 
in a DIAL program , the CAI System w ould route the prob3.em 
to one of the tutor stations. 

The situation is* a suitable candidate for a man- 
machine system. The instructional task would be parti- 
tioned such that the inherently algorithmic parts (text 
display, sequencing, etc.) are handled by the machine 
and the parts that are best handled by a man (pattern, 
context and judgment problems'; would be allocated to the 
tutor. 

The number of minutes per hour that the tutor spends 
on the average with each student must be very low for the 
system to even .approach cos t-ef feet ivenes s . 

In terms of the pressure characteristics of the 
system, the job of tutor would be similar to one in \.he 
busiest air traffic control center, wh ^e duty periods 
are as short as one hour. 
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Some of the challenges involved and questions raised 
are the following, 

1- Information display to the man 

The context surrounding the stadent unrecognized 
response must be displayed at the console of the tutor 
station in such a way that the tutor can quickly see the 
problem and decide on his response. 

2. Input from the man 

Once the man has decided what his response will be, 
he must be able to enter it quickly so he can be freed to 
serve the next problem. Thus typed input is excluded. A 
menu of responses to be selected, by light pen suggests 
itself. This menu should be part of the problem display. 
An obvious menu is the of branch labels appropriate 

to the problem section of the DIAL program. This, however, 
requires the man to be intimately familiar with every 
micro-point in the instructional program. An alternative 
for the menu might be a "soale of wx n ongness" which the 
System would translate into branch labels* 

The tutor console might enable the tutor to contro 1 
a pointer on the student's CRT screen. 



268 



3. Multiple interactions 

If the tutor cannot decide on an action for a 
particular problem, he may want to get more information 
from the student; a two-way channel for multiple inter- 
actions per problem is then needed. 

4. Instructional programming 

There are many implications for the instructional 
program structure and for the author language. 

While the situation proposed may never be implemented, 
it would serve as a models the investigation of which 
should throw light on important problems not only in man- 
machine dialogue 5 but also in learning theory. 

Finally, note that the system would be ideal for a 
HELP or HINT facility. When a student types HELP the 
system would display the context at the tutor station. 
The tutor could use a voice link for his reply. 

9 . 7 More servi ce pr ograms 

Much data is gathered by the CA1 System from each 
student session and stored in various files. Programs 
over and above the existing ones are needed to analyze 
this information for authors and proctors. A study 
should determine 
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(1) what information is pertinent; 

(2) a language for accessing it; 

( 3 ) whether batch or interactive programs should 
be used. 

There are three potential sources for information for 
analysis : 

1. The STJREC file 

Each student ! s record conta.ins statistics on terminal 
time, personal data and the number of recovers and resumes. 

2 . LOGFILE 

This contains, for each student session, student 
responses (typed or penned) and a trace by DIAL statement 
number diachronically . 

3 . The student activation record 

This record is called SCB (student control block) in 
the CAI System. It is not diachronic but a snapshot of the 
state of all variables , DIAL machine registers, etc., at an 
instant in time.- In contrast to the log file, SCB has 
instant in time but all in kind. At sign-off it is 
transferred into sfffcC . SCB_PART on the student ! s record in 
fJle STUREC. 
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The work at Florida State University [Davenport, 1968] 
on the analysis of Coursewriter-generated performance 
records may be useful in the study. 

i . 8 Color cathode-ray tube terminals 

In the Spring of 19 72 the CAI Project added a color 
option to the display of the work station , a very useful 
modification. It involved replacing the existing CC-300 
TV Display by a color TV and modifying the CC-301 TV 
Display Controller. Characters can be displayed in green, 
red, blue or yellow. 

Character color is specified by four (non-displayed) 
control characters. These codes are: 

(1) entered from the keyboard by simultaneous depression 
of the special code key (SP) and one of Q 5 R 5 S,or T , or 

(2) sent from The computer. 
Once a color selection has 

been made, all characters; received by the controller are 
stored with that color designation until the next color 
code is received. Thus color codes act as shift 
characters. But when a message is transmitted from the 
CC-301 to the computer these control characters cannot be 
retrieved. Because of this hardware deficiency, software 
is needed to transmit an encoding of these characters to 
the computer so that when messages are sent back the 
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appropriate color control characters will be inserted. 

An interim solution has been implemented. Four 
system text constants, GREEN , RED, BLUE, and YELLOW, were 
added tc the language. They can appear in a DIAL text- 
expression just as any other text constant. For example, 

SHOW 'The fallowing is an example of an 

| | RED J | arithmetic ? | j BLUE j | 'expression 1 . 
j ) A better solution, in that it does not intrude on 
the language , is to make colov changing part of the 
operational environment. Four light buttons (one for 
each color) at the bottom of the author mode display 
format could make color changing appear to be in the 
hardware. Thus , to show !! arithmetic" in red, as above, 
an author would enter 

SHOW 'The following is an example of an 
arithmetic expression. f 
but after ,! an !! he would pen the red light button. The 
cursor would then change color*, after "arithmetic" he 
would pen blue. 

This solution is perhaps as neat as can be done by 
software alone. The right solution from a human factors 
viewpoint requires minor hardware changes. 
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APPENDIX A 



QUESTIONNAIRE A AND SUMMARIES OF STUDENT 
RESPONSES 



For each question, four sets of responses are given 
They represent the totals from each class, as shown in 
the following example. 



2 
8 



15 



12 



7 
77 



Fall, 1972, Conventional 
method-Instructor 1 

Fal.' , 1972 , Conventional 
method-Instructor 2 

Fall, 1972, CAI 

Spring, 1973, CAI 



In the Fall, 58 students out of a possible 60 
completed the questionnaire. In the Spring, 55 out of 
a possible t9 completed it. 
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NAME : 



COMPUTER-ASSISTED INSTRUCTION STUDY 



FALL 1972 



Student questionnaire for control groups and experimental 
group 



Please fill out the attached questionnaire as completely 
and accurately as possible. The information gathered will 
help planning for more effective methods of teaching com- 
puter science courses . 

You will not be graded on your responses to this question- 
naire. In fact, neither your instructor nor the course 
supervisor will ever see any completed questionnaire. 
Neither will any student be listed or mentioned K y name or 
number in reports describing the results of this study. 



To be completed in class on Monday, October 2, 1972. 




J. C. Mudge 
Experimenter 



JCM/vj 
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Year at UNI 



2 


3 


4 


1 


5 


2 




5 


10 






2 


1 


9 


5 


6 


8 


14 


7 3 


72 



4 
3 

Fresh- Soph- Junior Senior Grad- Other (Please 
man omore uate specify 

Student ) 



Major or intended ma^or: 



How would you rate your attitude to the subject 
matter of this course? Restrict your rating to the 
subject matter itself, not the method or quality 
of instruction . 



9 4 3 

2 14 5 

9 .6 5 1 

14 34 7 1 

very very 

positive positive neutral negative negative 



What previous experience have you had with computers 

Circle all 
that apply: 



8 


12 


10 


37: 


none 






1 


5: 


other programming courses 




1 




7 : 


computer appreciation course 




1 


3 




this course before 


6 


6 


5 


73! 


use of pre-programmed packages-; 








3 : 


e.g., statistical packages 


1 


3 


2 


programming in language(s) other 










than PL/I 


1 


2 


5 


70: 


other (Please specify) 
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Why 


are 


you 


taking this course? 


Circle 


all 


that 


a rF 1 .y • 


1 


1 


2 


6: 


it is a prerequisite for other 










courses I plan to take 


2 






7: 


it is required in my program 


4 




2 


9: 


it satisfies the language re- 










quirement for a graduate degree 


6 


10 


9 


34: 


solely for a broadening 








7 7 : 


experience 


4 


3 


8 


it will help me get a job 


2 


5 




6: 


it satisfies the math requirement 










for my degree 


10 


12 


15 


47: 


programming will be a useful ' 










research skill 


3 


6 


2 


7: 


other (please specify) 



a) At the beginning of the semester I felt that 
obtaining a good grade in the course was 



4 10 2 

13 8 

6 12 3 

22 25 9 

very important somewhat not important 

impo rtant 



b) At this time, I feel that obtaining a good grade 
in the course is 



3 11 2 

13 8 

7 9 5 

27 2 5 7 0 



very important somewhat not important 

important 



277 
Page 4 



7. (a) In comparison with courses which have a similar 
relationship (e.g., elective, required course) 
to my program, the amount of time I now" allot to 
this course is 



5 
6 
13 



9 
12 

6 
28 



2 
2 
1 
14 



1 
2 



much 
more 
than 
average 



nore 
than 
average 



average 



less 
than 
average 



much 
less 
than 
average 



At the 


beginning of 


the course 


I had exp 


ected 


time allocation to 


be 






6 


8 


2 






1 


15 




1 




2 


12 


7 






S 


30 


17 


7 




much 


more 


average 


less 


much 


more 


than 




than 


less 


than 


average 




average 


than 



average average 

; 

This course ( has been frustrating: 

17 6 2 

1 5 10 5 

3 4 12 2 

3 5 • 2 g 75 



all of most of some of only never 

the time the time the time occasionally 
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9. (a) With respect to intellectual challenge, before I 

began the course I expected the subject matter 
to be 

3 8 5 

2 13 5 1 

2 11 8 

6 37 ' 13 



very challenging about trivial very 

challenging average trivial 



(b) With respect to intellectual challenge, I would 

now rate the subject matter as 

2 i+ 9 ' 1 

5 11 5 

7 11 2 1 

10 2 9 U 1 

very challenging about trivial very 
challenging average trivial 



10. (a) Before I began the course I would have rated the 

subject matter as 

5 7 3 1 

2 17 2 

8 10 3 

IS 35 9 



very valuable about worthless very 

valuable average worth- 

less 



0 

ERIC 
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10. (b) I now rate the subject matter as 

5 7.3 1 
2 17 l i 

6 9 6 
9 36 n 



very valuable about worthless very 

valuable average worthless 



11. Do you believe that teaching can be automated? 

12 4 

10 ii 

15 6 

36 17 

yes no 



APPENDIX B 



QUESTIONNAIRE B AND SUMMARIES OF STUDENT 

RESPONSES 



For each Question, two sets of responses are given. 
The italicized set represents the total from the Spring 
class 5 the other set represents the Fall class . Some . 
questions, e.g., Section III, Questions 10 and 11, were 
not applicable to the Spring class and so were not 
printed on the Spring questionnaire. 

Section II of this questionnaire is a "student 
reaction inventory""'" developed at Pennsylvania State 
University. 

In the Fall, 21 students out of a possible 2 2 
completed the questionnaire. In the Spring, 56 out 
of 69 completed Sections I to III, and 3 6 out of 69 
completed Section IV. 



'he- Development and Presentation of Four College 



Courses' fry Computer Teleprocessing . Computer Assisted 
Instruction Laboratory, The Pennsylvania State University, 
University Park, Pennsylvania. June 30 5 19 67. 
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NAME: 



COMPUTER-ASSISTED INSTRUCTION STUDY 



FALL 19 72 



Student Questionnaire for the CAI Group 



Please fill out the attached questionnaire as completely 
and accurately as possible. The information gathered will 
be used to enhance the Department of Computer Science f s 
CAI System. We are seeking information 5 not compliments; 
please be frank. 

You will not be graded on your responses to this question- 
naire. Neither will any student be listed or mentioned 
by name or number in reports describing the results of 
this study. 



Sections I, II and III are to be completed in class on 
Monday 5 * October 2, 1972 . Section IV is to be handed in 
at the beginning of class on Wednesday, October 4 5 1972. 




J. C. Mudge 
Experimenter 



JCM/vj 



282 



SECTION I 



I have had contact with computer-assisted instruction 
prior to this course: 



20 1 
51 5 



no yes (please specify) 



My initial reaction when informed that the first weeks 
of instruction would be by CAI was 

12 6 3 

9 - 30 U . . 5 



very favorable indifferent unfavorable very 
favorable unfavor- 

u able 



I enjoyed the scheduling freedom provided by CAI 

6 15 

7 4 21 30 



strongly disagree uncertain 
disagree 



agree 



strongly 
agree 
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4. I use a typewriter keyboard 

7 7 4 3 

7 2 32 8 2 



by touch by touch hunt-and- hunt-and- (not familiar 
fluently halting- peck peck with a type- 

ly . rapidly haltingly writer 

keyboard) 



5. I prefer the lesson units to be 



3 15 2 

9 44 3 



longer the length shorter 

they were 

6. My first and second choices for lesson length are 
[Responses were weighted for - 2 for first choice, 
1 for second. ] 



8 11 11 13 8 

2 16 4 1 54 48 

10 mins 20 mins 30 mins 45 mins 60 mins 



7. I would like more opportunity during a CAI session 
to review 

2 15 13 

2 43 3 8 



complete 
lessons 



parts of lessons s 
both slides and 
questions 



slides only (no review) 
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. I reviewed slide handouts between CAI sessions 

3 8 5 '3 2 

12 7 5 16 11 2 

all the most of some of only never 

time the time the time occasionally 



9. After each CAI session I would like a printed copy of 
the questions and answers covered in the session 

1 5 15 

J 4 2 4 2 7 

strongly disagree uncertain agree strongly 
disagree agree 



10. For entering my answer to a multiple-choice question, 
I prefer to use 



5 16 
19 34 

the light pen numbers entered from 

the keyboard 



11. Messages on the TV screen were removed too quickly 

-3 6 11 1 

10 25 21 

all the most of some of only never 

time the time the time occasionally 



Z8b 
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12. I prefer to press INT to signal when I have read a 
message on the TV screen 

1 12 8 

4 32 10 



strongly disagree uncertain agree strongly 
disagree agree 



13. Some slides had no questions. , I prefer one or more 
questions after each slide 

2 7.6 5 1 

1 22 18 12 3 

strongly disagree uncertain agree strongly 

disagree agree 



14, I found the weekly question-and-answer sessions with 
the instructor to be 

7 11 3 

5 30 1 % 3 



very sometimes not very (I didn't go) 

helpful helpful helpful 
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Assuming three contact hours per week 5 what would be 



the best balence between CAI and in-class instruction? 

6 12 1 2 

10 39 4 2 

CAI hours 3 2 10 

in-class hours 0 12 3 

Compared to a regular in-class lecture, duixng a CAI 
session I felt I had to concentrate 

5 10 4-2 

11 30 9 6 



much more more cibout the same less much 

less 



When I entered an answer the computer responded with 
adequate speed 



4 16 1 

5 38 9.4 

all the most of some of only never 

time the time the time occasionally 



section it 



CIRCLE THE RESPONSE THAT MOST M EARLY REPRESENTS YOUR 
REACTION TO EACH OF THE STATEMENTS BELOW: 



1. V/hile taking Computer Assir-ted Instruct Ion I I e 1 *. 
challenged to do my Lost work, 

3 M 0 



Strongly Disagree Uncertain Ag^o*: Strong! y 
Disagree Agree 



2. The material presented to me by Computer A^tvj r>teO 

Instruction caused me to feel that no one really 
cared whether I learned or not . 

7 12 1 ) 

12 34 6 2 7 

Strong ly Disagree JJn certain Agree S 7; rong J y 

Disagree Agree 



3. The method by which I was told whether I had giv- 
a ri?ht or wrong answer became monotonous. 

2 7 3 . . 

3 24 ? 12 t 

Strongly Disagree Uncart a in Agree '.•>;."';.';}.;. y 
Disagree " Agrfc* 
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I was concerned that I might not be understanding the 
material . 

1 5 2 12 1 

1 11 6 IS 4 

Strongly Disagree Uncertain Agree- Strongly 
Disagree Agree 



I was not concerned when I missed a question because 
no one was watching me anyway. 

7 9 5 

9 28 6 13 

Strongly Disagree Uncertain Agree Strongly 
Disagree Agree 



6. While talcing Computer Assisted Instruction I felt 
isolated and alone. 

2 3 3 13 

3 4 4 76 19 

All the Most of Some of Only Never 

time the time the time occasionally 



7. While taking Computer Assisted Instruction I felt as 
if someone were engaged in conversation with me- 

115 6 8 

4 7 17 10 18 

All the Most of Some of Only Never 

•time the time the time occasionally 
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The responses to my answers seemed appropriate. 

m -6 1 

1 lb 11 6 7 

All the Most of Some of Only Never 

time the time the time occasionally 



9. I felt uncertain as to my performance in the programmed 
course relative to the performance of others . 

3 3 5 7 3 

4 7 7 2 7 7 75 

All the Most of Some of Only Never 

time the time the tim-3 occasionally 



10. I found myself just trying to get through the material 
rather than trying to learn. 

1 ' 1 5 7 7 

1 1 U 2 7 7 3 

All the Most of Some of Only Never 

time the time the time occasionally 



11. I knew whether my answer was correct or not before X 
was told. 

if . 7 6 3 1 

3 3 7 7 5 5 1 

Quite Often Occasionally Seldom Very Seldom 

often 



12. I gue?3sed at the answers to questions. 

1 1 11 2 6 

1 2 30 16 6 



Quite 
often 



Often 



Occasionally Seldom 



Very Seldom 
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13. In a situation where I am trying to learn some 'ling, 
it is important to me to know where I stand relative 
to others . 

3 11 1 4.2 

f 6 25 13 H 1 

Strongly Disagree Uncertain Agree Strongly 

Disagree Agree 

14. I was encouraged by the responses given to my answers 
of questions. 

1 3 7 9 1 

1 14 17 23 

Strongly Disagree Uncertain Agree . Strongly 

Disagree Agree 



15. As a result of having studied some material by Computer 

Assisted Instruction, I am interested in trying to find 
out more about the subject matter. 

12 5 11 2 

6 15 34 1 

Strongly Disagree Uncertain Agree Strongly 
Disagree Agree 



16. In view of the time allowed for learning, I felt too 
much material was presented. 

1 5 '87 

2 4 14 36 



All the Most of Some of Only Never 

time the time the time occasionally 
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17. I was more involved in running the machine than in 
understanding the material. 

2 7 12 

7 2 5 31 17 



All the Most of Some of Only Never 

time the time the time occasionally 



18. I felt I could work at my own pace with Computer 
Assisted Instruction. 

12 9 9 

3 7 32 20 

Strongly Disagree Uncertain Agree Strongly 

Disagree Agree 



19. Computer Assisted Instruction makes the learning too 
mechanical . 

5 11 ' 2 2 1 

73 32 6 5 

Strongly Disagree Uncertain Agree Strongly 

Disagree Agree 



20. I felt as if I had a private tutor while on Computer 
Assisted Instruction. 

1 7 2 10 ■ 1 

1 21 77 16 7 

Strongly Disagree Uncertain Agree Strongly 

Disagree Agree 



21. I was aware of efforts to suit the material specifi- 
cally to me . 

15 9 6 

6 24 16 9 1 

Strongly Disagree Uncertain Agree Strongly 

Disagree Agree 



ERLC 



?. f j 7. 



22. I found it: difficult to concentrate 
material because of the hardware. 



on the courne 



11 
24 



10 
1% 



All the Most of Some of Only Never 

time the time the time occasionally 

23. The Computer Assisted Instruction situation made me 
feel quite tense. 

7 11 2 1 

U 33 2 3 

Strongly Disagree Uncertain Agree Strongly 
Disagree Agree 



24. Questions were asked which 
to the material presented. 

1 

/ 4 

All the Most of Some 
time the time the t 



I felt were not relevant 



10 10 
30 2 1 

of Only Never 

ime occas icnally 



2 5. Computer Assisted Instruction is an inefficient use of 
the student 1 s time. 

8 10 3 

2/ 25 5 4 7 

Strongly Disagree Uncertain Agree Strongly ■ 

Disagree Agree 



26. I put in answers knowing they were wrong in order to 
get information from the machine. 

118 4 7 

7 6 27 75 73 

Quite often Often Occasionally Seldom Very Seldom 
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27. Concerning the course material I took by Computer 

Assisted Instruction, my feeling toward the material 
before I came to Computer Assisted Instruction was: 



3 11 5 2 

5 33 77 

Very Favorable Indifferent Unfavorable Very 

favorable Unfavor- 
able 



28. Concerning the course material I took by Computer 

Assisted Instruction, my feeling toward the material 
after I had been on Computer Assisted Instruction is: 



2 17 2 

g 37 9 

Very Favorable Indifferent Unfavorable Very 

favorable Unfavor- 
able 



29. I was given answers but still did not understand the 
questions . 

1 11 3 6 

/ 3 2 8 14 10 



Quite often Often Occasionally Seldom Very 

Seldom 



30, While on Computer Assisted Instruction I encountered 



mechanical malfunctions . 

1 10 6 4 

2 6 24 1 2 1 1 

Quite often Often Occasionally Seldom Very 



Seldom 




2\. Ml 



31. Computer Assisted Instruction made it possible for me 
to learn quickly . 

5 12 3 

1 5 11 24 5 

Strongly Disagree Uncertain Agree Strongly 
Disagree Agree 



32. I felt frustrated by the Computer Assisted instruction 
situation . 

3 12 3 2 1 

7 7 37 6 6 7 

Strongly Disagree Uncertain Agree Strongly 

Disagree Agree 



33. The responses to my answers seemed to take into account 
the difficulty of the question. 

7 6 8 

7 79 77 77 7 

Strongly Disagree Uncertain Agree Strongly 

Disagree Agree 



34. I could have learned more if I hadn T t felt pushed. 

4 8 6 2 1 

6 35 7 6 

Strongly Disagree Uncertain Agree Strongly 
Disagree Agree 



35. The Computer Assisted Instruction approach is 
inflexible . 

1 9 4 6 1 

7 38 10 5 7 

Strongly Disagree Uncertain Agree Strongly 

Disagree Agree 



9 

ERLC 



Even otherwise interesting material would be boring 
when presented by Computer Assisted Instruction. 



4 



14 
37 



2 
4 



Strongly 
Disagree 



Disagree Uncertain 



Agr£e 



Strongly 
Agree 



In view of the effort I put into it, I was satisfied 
with what I learned while taking Computer Assisted 
Instruction, 



1 
2 

Strongly 
Disagree 



3 13 
6 5 36 

Disagree Uncertain Agree 



4 
6 

Strongly 
Agree 



In view of the amount I learned, I would say Computer 
Assisted Instruction is superior to traditional 
instruction . 



2 
2 



1 

13 



1 
IS 



7 

77 



4 
4 



Strongly 
Disagree 



Disagree Uncertain 



Agree 



Strongly 
Agree 



With a course such as I took by Computer Assisted 
Instruction, I would prefer Computer Assisted 
Instruction to traditional instruction. 



1 
2 



3 
7 



2 
17 



10 
2/ 



Strongly Disagree Uncertain Agree Strongly 

Disagree Agree 



2 96 



L am not in favor of Computer Assisted Instruction 
because it is just another step toward cJe-personaiizod 
instruction . 

5 14 11 

10 29 S 7 1 



Strongly Disagree Uncertain Agree Strongly 
Disagree Agree 
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SECTION III 



The West House CAI Center was a smoothly running 
operation . 



15 
41 



6 
6 



all the most of some of only never 

time the time the time occasionally 



How long did it take you to get used to the operation 
of the CAI System? 

minutes 



15 



10 




40 



50 



60 



Did you receive adequate instruction in operating the 
work station? 



15 
53 



yes 



no 

(please suggest improvements) 
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Section III 
Page 2 

How many scheduled CAI sessions did you miss because 
the CAI System was inoperative? 



0 


8 
43 


1 


9 
7 7 


2 


4 
3 


3 


1 

4 






4 


7 



How many scheduled CAI sessions did you miss because 
the next batch of course material was not ready? 



0 


12 


1 


7 


2 


2 


3 


1 



During my CAI sessions I requested help from the 
proctor 

1 8 11 1 

7 7 5 32 4 I 



quite often often occasionally seldom very seldom 
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7. I consider the availability of a proctor to be 
17 3 1 

essential highly desirable desirable not essential 



8. I consider the proctor call switch to be a good 
method of summoning the proctor. 

17 if 
54 1 



yes no 

(Please give reason) 



9. When I needed assistance from a proctor I felt he was 
familiar with Dr. Brooks's course material. 



7 11 1 2 

27 79 4 2 2 

all the most of some of only never 

time the time the time occasionally 



10. For experimental control reasons, the proctor was not 
allowed to answer subject matter questions • 
If this restriction was removed I would prefer to be 
able to ask the proctor questions on the subject 
matter. 

13 12 5 



strongly disagree uncertain agree strongly 
disagree agree 
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11- I had difficulty reading the black-and-white slides 

14 8 8 

all the most of some of only never 

time the time the time occasionally 



12. Viewing the TV screen and slide screen resulted in 
eyestrain 

8 13 
2 4 12 37 



all the most of some of only never 

time the time the time occasionally 



13. I found the work station room to be 
(Circle all that apply) 

2 .18 
6 2 7 7 2 2 29 

too cold too hot stuffy too noisy comfortable 



14. I prefer the room lighting to be 



9 12 
4 3 S 

on off 



15. I prefer to work with the work station door 

3 18 
10 44 



open closed 



ERIC 
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16. I prefer the keyboard height to be 



20 1 

J 52 ' 2 

lower about the same higher 

17. I was distracted by noise outside the work station 

6 15 

7 48 

often sometimes never 



18. I felt uncertain as to how I should be making use of 
the prescribed texts for this course 

1 1 1 m 4 

2/3 5 26 9 

strongly disagree uncertain agree strongly 

disagree agree 
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NAME: 



Student Questionnaire for the CAI Group 



SECTION IV 



(To be handed in at the beginning of class on Wednesday, 
October 4, 1972) 



1. A hint facility in a CAI system would respond with an 
author-prepared hint when requested during a question/ 
answer sequence. 

I view such a hint facility as 



mandatory highly desirable desirable not necessary 



2. A definition facility in a CAI system would allow a 
student to consult an author-prepared dictionary or 
glossary stored in the system. Sample student 
requests might be 



6 
4 



11 
IS 



4 
U 



) define 



variable 



)def ine 



) define 



INDEX 



I view such a definition facility as 



3 
7 



10 
27 



8 
7 



mandatory highly desirable desirable not necessary 
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3. A student-controlled review facility in a CAI system 
would enable a student to request a review at any time 
in a session. The request )review would result in the 
display of a menu of topics available for review- The 
student would light pen his selection. 

In the CAI course you have just taken, opportunities 
for review were given in later lessons and then only 
at author-specified points. 

, I view a student-controlled review facility as 

9 7 4 1 

7 H 9 2 



jd mdatory highly desirable desirable not necessary 



4. I would like all of the courses this semester to be on 
the CAI system 

3 6 5 5 2 

9 12 8 4 2 

strongly disagree uncertain agree strongly agre 
disagree 

[This question is of doubtful use because of a typo- 
graphical error - I intended "courses" to be singular.] 



5. I suggest the following improvements to the work 
station: 

6. I suggest the following improvements to the West House 
operation : 

7. Of the courses I have taken I feel that the following 
are suited to presentation by CAI: 



8. Any other comments: 



JCM/vj 
1072 



30^ 



APPENDIX C 
POSTTEST 



( 5 min.) 1. What is an algorithm? Give a brief 

example of an algorithm. 



(10 min.) 2. Distinguish between variables and values 

How may variables be given values? 



( 5 min.) 3. Find all of the errors in each of the 

PL/C statements below. Use the space 
provided beneath each statement to 
describe the errors in the statement. 
If a statement contains no errors, indicate 
this by writing NO ERRORS FOUND beneath 
the statement. 

LABEL 1: GET LIST X,Y,Z; 
A + B = C; 



X - 24X + Y; 



(10 min.) 4. Two numbers are in variables FIRST and 

SECOND. Write a PL/C statement using IF 
to put the larger number into a variable 
called BIG. Assume everything has been- 
properly declared . 



9 

ERJC 
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(20 min . ) 5. What is the output from this program? 

Draw a box around your answer. 

Hint : Trace through the program as if it 
were executing. Note each change 
in the value of any variable. If 
your answer is incorrect, any 
partial credit given will be based 
on your trace. If necessary, you 
may use the blank page following this 
one . 



PGM: PROC OPTIONS (MAIN); 
DCL (I,Y) FIXED; 
DODO : DO I = 1 TO 5 ; 
GET LIST (Y) ; 
IF Y < 5 THEN L: DO; 

PUT LIST (Y) ; 
Y = 2 * Y ; 
END L; 

PUT LIST (Y) ; 

END DODO; 
END PGM; 
'''DATA 
1, 2, 4, 8, 16 
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